Posted 26 August 2012 - 06:48 AM
When it comes to singletons, I think their shortcomings are kind of exaggerated. I feel like this is one of those things that small kids are told not to do (like don't pee in your pants). Most of the time, it's just that programmers with experience that keep on preaching it's bad (cause it's one of those widely accepted things like "don't use goto") to get recognition from peers. And since everybody happily agrees, newbies don't get to have a coherent explanation as to why - they are often left with a list of "don't-s".
The singleton pattern is very useful, because it allows you to guard the access to global variables. The idea with patterns is that you shouldn't take them too seriously. They are just solutions to problems, usually making the least evil possible in a bad situation. You should, rather, take the core idea and modify it to suit your case. A slight variation of the singleton pattern is the immutable object, which is universally accepted as a good thing. Or your singleton can be unique per thread, per GUI window, per player, etc.
The worst thing about singletons is that they make your API hard to discover, since you have to know they exist. Also, they are very difficult to change. This applies not just to singletons, but to any static method that you have to know that has to be called at any point. Static methods are an abomination, IMO, but since some language authors decided that "thou shalt only have objects", it is the only way to have global functions.
About your UI dilemma - I'd suggest data-driven UI. Make up an XML or JSON schema and define your UI in it. If you are punished to use C++, you'll have to have some pure abstract class for registering actions that get invoked in the XML, so that your UI loader would be something like loadUI(fileName, callbackHandler). The callback handler would respond to any action invoked in the declarative UI by name. In languages that support metadata (or if you make UI logic as DLL plugins in C++), you'd just dynamically load the callbacks. That's how I'd do it, since I've grown to like declarative programming, I really think it allows you to experiment with UI options much more than "normal" code that has to be recompiled. And since it's data-driven, you can employ RAII and stuff as much as you want in the reader.
If you are using C++, you can't just give up objects, because of all the memory management and exception safety "happiness". I don't really know any other sane way for managing resources other than RAII.