Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application’s toolbox is a singleton that is responsible either for configuring itself or for allowing the application’s startup mechanism to configure it.
Now I hope I have learned something. There’s a big refactoring session coming up anyway.
The project is well on it’s way in getting too complex …. *must do something, must make simple, must refactor*