title: Good OO design - The Singleton Design Pattern
body: <p>All of a sudden I'm having a bit of an OO crisis. Over the last couple of years I've made quite good use of Singleton objects. I used them in many places.</p>
  
  <p>For example, in designing an MVC Java application, I'd create a Singleton 'SystemRegistry' class to store the model and view classes (I've only worked on simple apps and the need for multiple views never came up).</p>
  
  <p>When I create my model and view objects (which weren't singletons, just normal objects), I'd do something like:</p>
  
  <pre><code>SystemRegistry.getInstance().setModel(model);
  </code></pre>
  
  <p>In my controller classes (which were pretty much event handlers for different GUI items), I'd get access to the view or model as follows:</p>
  
  <pre><code>SystemRegistry.getInstance().getView();
  </code></pre>
  
  <p>I would never use the SystemRegistry class in the model portion of my app but would, at times, use it in my view to access (but rarely, if ever, to modify) information from the model.</p>
  
  <p>From what I've read (notably <a href="http://sites.google.com/site/steveyegge2/singleton-considered-stupid" rel="noreferrer">Steve Yegge's article</a>), this seems like a poor way to design my application. Any ideas as to better ways of structuring my code.</p>
  
  <p>Also, another aspect of how I design classes, which may, or may not be related to Singletons, is the use of 'Manager-type' classes. An example is a (very simple) OpenGL-based game engine I created in C++.</p>
  
  <p>The main class was GameEngine. It was the over-arcing class that stored a bunch of Managers and handled the main loop and what not. Some of the Managers stored in this class were things like:
  ObjectManager, RenderingManager, LightingManager, EventManager (includes input), HUDManager, FrameRateManager, WindowManager, etc. There were probably a few more as well.</p>
  
  <p>Basically these classes handled the different aspects of the game engine. The names are pretty straightforward so you should be able to get a good idea of how they're used.</p>
  
  <p>Now, this was meant to be a reusable base that I could use in different projects with the need to change it ideally.</p>
  
  <p>In each new game, I would create an instance of the GameEngine as a class-wide variable (most of the game logic was stored in a single class) and set up the different managers (for example, loading the window co-ordinates or lighting details from a file, setting the FPS, etc). To register an object in the ObjectManager I would do something like:</p>
  
  <pre><code>Player player = new Player();
  gameEngine.getObjectManager().addObject(player);
  </code></pre>
  
  <p>This object will now be stored in a vector in the ObjectManager class and will be drawn when the GameEngine calls the ObjectManager drawObjects() method in each frame.</p>
  
  <p>I might've gotten a bit paranoid now after that article on Singletons (and might not have had enough time to wrap my head around it), but I'm starting to second guess and wonder if the way I designed my GameEngine was proper (for lack of a better word) and didn't just fall into the same pitfalls shared by the Singleton pattern.</p>
  
  <p>Any comments on my post would be much appreciated.</p>
  
  <p><strong>Edit:</strong> Thanks for the answers. I appreciate them greatly. If possible, I'd love if someone could give me some hints regarding the two project scenarios posted above. How could I have avoided the use of Singletons / Managers?</p>
  
  <p>With the first one, would DI have been the correct response? Should I have even given the view access to the model (this is probably more of an MVC response)? Would the view benefit from implementing an interface (so that multiple different views can be plugged in)?</p>
  
  <p>In the second case, how else could one have structured the application? Is the gripe simply the use of Manager classes as opposed to more specific names? Or is it that, in some cases, the classes can be further broken-down (e.g. ObjectHolder, ObjectDrawer, ObjectUpdater)?</p>