The Singleton Design Pattern

• For today, I have a much simplified version of the game.
  • Look at simulation.cpp
• I have a problem with the game.
  • It is way too verbose.
• We need the verbosity for debugging.
  • And possibly at times to enjoy the game.
  • But the game is just not playable as it is.
• A reasonably simple solution is to add a logger.
  • This is an entity that handles information to be sent to a log.
  • Information is logged at a "level".
    • The higher the level, the less important.
  • The system can then control the level of output by notifying the logger of the level of detail to print.
• It might look something like this

  • enum class LogLevel {HIGH, MEDIUM, LOW};
    
    class Logger {
          void SetLevel(LogLevel level);
          void Log(string msg, LogLevel level);
    } 

  • If you wanted to, you might consider writing to a file.
    • In this case, you would need a constructor to open the file.
    • And a destructor to close the file.
  • You could also pass an open stream if you wanted.
• Everything would change the way it worked.

  • void SectorProduce(int x, int y){
       cout << "Producing in sector " << x << ", " << y << endl;
       return;
    } 

  • would have to change to something like

  • void SectorProduce(int x, int y, Logger & logger){
       string msg;
    
       msg = "Producing in sector " + to_string(x) + ", "  + to_string(y) + "\n";
       logger.Log(msg, LogLevel::LOW);
       return;
    }   

• This is not satisfying in at least two ways.
  1. I loose all access to the stream insertion operator.
     • There is a ton of work put into making this work.
     • And all of that is gone.
  2. I have to pass the logger to ALL functions that will do I/O.
     • This is a mess.
     • It is not clean.
     • Why do I have to pass this logger everywhere?
• The solution to the first part is a stringstream.
  • Discussed on page 425
  • Reference
  • This is an ideal solution to our problem.
    • You need to include <sstream>
    • It is part of the standard library.
    • The type is stringstream
    • There are a number of operations you need to know about
      • .str() returns the string currently stored in the stream.
      • .str(string) sets the string currently stored in the stream.
      • The stream insertion and stream extraction operators work as expected.
      • You can perform most other stream related operations as well.
      • But we only need these three.
  • Our code becomes

  • void SectorProduce(int x, int y, Logger & logger){
       stringstream output;
    
       output << "Producing in sector " << x << ", " << y << endl;
       logger.Log(output.str(), LogLevel::LOW);
    
       // not required but I wanted to show this here.
       output.str("");
    
       return;
    } 

• There is still the second problem.
  • We COULD declare a global instance of the logger.
    • But I can't really express the aversion I have to global variables.
      • The real solution is the Singleton Design Pattern
    • Design Patterns
      • Design patterns are introduced in chapter 29 of your book.
      • They are a standard approach to program organization that solve a general problem
      • They are well known solutions to well known problems.
    • The singleton pattern
      • Discussed in detail on page 993 - 997
      • As a logger.
      • This pattern is applicable when
        • There should exist only one instance of an object
          • Our logger for example.
          • Or a resource allocation object.
        • The instance should be available everywhere, everywhen.
        • There is no single point of creation.
      • This is not a solve everything solution.
        • In threaded environments you need to be careful to make sure thread safety is maintained.
        • If there are multiple singletons, they can't depend on each other.
        • They increase code dependency.
    • Some background is needed.
      • Static variables extend the life of a variable.
        • See the current implementation of the game, in the AI section.
        • These should also be used sparingly.
        • IE Not as an excuse to avoid parameters.
        • They are initialized once, on first entrance to the function.
        • And not reinitialized after on further calls.
        • They are destroyed when the program terminates.
      • Static members of classes are different.
        • For data, a static class member is shared across all instances of the class.
          • We will look at these next time.
      • Static methods
        • See page 251
        • Static methods also are shared across all instances of a class.
        • They do not have access to member variables.
        • They do not have access to the this variable either.
        • They can be called without creating an instance of the class.
          • You just call it with the class scope.
    • Back to the singleton class.
      • We will take advantage of static methods and a static variable to implement this.
      • First put the constructor in the private section.
        • On the surface, this appears insane, you can't construct a version of the class.
        • Remember, only functions in public can be called.
      • Second declare a static member function Instance()
        • It declares a static instance of the class.
        • Since it is static, it is initialized only once, the first call to Instance.
        • Since Instance is in the scope of the class, it is allowed to call the constructor.
        • This returns a reference to this instance.
        • To access the logger just do Logger::Instance()
        • The static keyword is one of many that are only used in the implementation or the header file but not both.
      • You want to disable the other "constructor" type functions
        • Copy constructor, assignment operator,
        • And later move operator and move constructor.
          • We will ignore these for now.
        • You need to be careful with these.
          • There are many situations where the compiler will create them for you.
          • You need to explicitly deny access
            • Like putting them in the private area.
          • Or better yet, do not allow the compiler to create them for you.
            • Logger(const Logger &) = delete;
            • See page 215 for example.
            • This is the preferred method.
    • Finally I declared a default argument to Log
      • These are discussed on page 257
        • Starting with the last (rightmost) parameter.
        • You can specify a default value.
          • Log(string msg, LogLevel level = LogLevel::LOW);
          • You can then call this function with one or two arguments.
          • If only one is given, the second will be the default.
        • You can do this for multiple parameters.
          • If you do this with a constructor, and you provide all parameters you can not supply a default constructor.