C++ In Theory: The Singleton Pattern, Part I - Statics are not Singletons
(Page 3 of 5 )
Forcing the existence of only one instance of the Log class seems easily implemented when we use only static variables and functions:
class Log {
public:
static void Write(char const *logline);
static bool SaveTo(char const *filename);
private:
static std::list<std::string> m_data;
};
In log.cpp we need to add
std::list<std::string> Log::m_data;
Though it looks like it fulfills our goal, there are some downsides to these kinds of singleton implementations. First of all, the construction and destruction of static member variables are difficult to localize. They are instantiated in any sequence by grace of the compiler, outside any constructors. This can cause tremendous problems when singletons depend on the right construction/destruction sequence
Second, it is not possible to implement polymorphic behavior this way because static functions cannot be virtual. This means that a singleton implemented with static variables/functions cannot be accessed through its baseclass. For example, when our application runs standalone on a machine we probably want to save the log to a file, but when it is part of a distributed application we might want to save the log to a logging server. Instead of bundling all functionality into one big fat "does-everything" class, we split the behavior up in to separate classes, all implementing the interface of the abstract baseclass:
// LogBase.h
class LogBase {
public:
virtual ~LogBase() {}
virtual void Write(char const *logline)=0;
virtual bool SaveTo(char const *filename)=0;
};
The destructor of our baseclass has to be declared virtual, otherwise the destructor of a derived class will not be called when it is destroyed through the baseclass.
// LogFile.h
class LogFile : public LogBase {
public:
virtual ~LogFile();
virtual void Write(char const *logline);
virtual void SaveTo(char const *filename);
private:
std::list<std::string> m_data;
};
// LogNetwork.h
class LogNetwork : public LogNetwork {
public:
virtual ~LogNetwork();
virtual void Write(char const *logline);
virtual void SaveTo(char const *filename);
virtual void SetServer(TCPConnection const &server);
private:
TCPConnection m_logServer;
std::list<std::string> m_data;
};
It is good to give each class its own responsibility, and to choose which Log class you will use during runtime. This prevents us from having to instantiate code we will not need:
int main(int argc, char *argv[])
{
LogBase *myLog = NULL;
if (argc == 1)
{
ShowUsage();
return –1;
}
if (strcmp(argv[1], ”-StandAlone”)==0)
myLog = reinterpret_cast<LogBase*>(new LogFile);
else if (strcmp(argv[1], “-Networked”)==0)
{
TCPConnection fictServer(“127.0.0.1:31280”);
LogNetwork *logPtr = new LogNetwork;
logPtr->SetServer(fictServer);
myLog = reinterpret_cast<LogBase*>(logPtr);
}
else
{
ShowUsage();
return –1;
}
/* more code here */
// logging example
myLog->Write(“test line going to either a file or network log.”);
}
This is of course a fictional example, but I hope you get the idea of what polymorphic behavior can mean for your application. In the example above, application code can log through the LogBase class, but depending on the arguments given during start-up, the logs will either be written to file or to a network server.
Next: The Gamma Singleton >>
More C++ Articles
More By J. Nakamura
/ 57 
