   To singleton or not to singelton, that is my question!
  Hot damn, that was a lamn title. Ah well.Anyway, I've done what I always like doing, starting on a new engine. I'm not doing much different this time, this one has the normal statemachine, logger and so on, but I've hit a problem. It's nothing major, and it's not preventing me to code, but it keeps me up at night...Basically, pretty much all objects that could go wrong will need access to the logger, to log there messages. Also, a fair few components of objects need to get to the VideoDriver interface to say "render this" etc. I can't decide whether to make my GameEngine (the main 'hub' that contains all the other classes) a singleton, pass this through as a constructor, or pass each small object (like the logger).I don't like the singleton approach, nor passing the game engine, but they are both the easiest solutions and most managable. However, passing the logger seperatly makes more sense.Are there any other ways people can suggest, and what do you think is nicest?   
  The logger is a low enough level item to be made a singleton, but think carefully about multiple log-files and multiple log sources, you may just want to pass log instances around.   ;  Logging as a strategy, not an object or actor.   ;Quote:Original post by TelastynLogging as a strategy, not an object or actor.What do you mean by stratergy? I only know this term in the lines of the startergy design pattern.   ;Quote:Original post by acid2Quote:Original post by TelastynLogging as a strategy, not an object or actor.What do you mean by stratergy? I only know this term in the lines of the startergy design pattern.As that. In my experience, using the strategy (and decorator) pattern for logging provides great flexibility and allows better reuse with little downside.   ;  But how can the stratergy pattern by applied when many objects wish to access one? Do you propose having a logger field in each class that requires it, and setting that? All I know is that the stratergy pattern is for when one class needs many different algorithms or routines, and so the stratergy pattern can group them all together.   ;  I have a strong dislike for singletons, pretty much put them in the realm of lazy programming, bad design or future vision :-).  That being said, our logger is a singleton.  It has access to multiple files, etc.  Until I get time, the urge or get annoyed enough to change it, it's staying a singleton.  It's the one place I can nearly justify it in my head :);  The "Logger" is a rather unique class, in that it will be used by classes which don't care about it. Additionally, pragmatics demand a simple, robust design so that instability doesn't bring it down. My suggestion: Just use a global variable.   ;Quote:Original post by acid2But how can the stratergy pattern by applied when many objects wish to access one? Do you propose having a logger field in each class that requires it, and setting that? All I know is that the stratergy pattern is for when one class needs many different algorithms or routines, and so the stratergy pattern can group them all together.Not every one, but as needed. Sound classes would look for the sound logger, while video ones might look for another which may or may not be going to the same log. Makes it easier to add info to the log message, and to seperate modules since they're all not tied to a logger defined elsewhere.*shrug* logging is one of those things that can be done many ways and is fine as long as it works.   ;  Make a logger manager that allows consumers to find a particular logger by name.  The logger manager should be a static class or namespace with global functions ("monostate") rather than a singleton to avoid writing extra code or wasting naive "Get()" calls/dereferences.  It will be lightweight enough that if you ever need to refactor it into an instanced class, you can do it in 5 minutes.   