An alternative to the Singleton pattern?

Question

I'm trying to design a more flexible form of Singleton.

The problems I'm trying to address are the following:

• Singletons cannot be tested easily.
• They abuse the object oriented approach by not allowing inheritance, the code becomes linear and many developers tend to over-use them.
• They are limited to one instance, in the sense of duplicating the same mechanism without duplicating the class itself (e.g., the way ThreadPool operates as a singleton for every application, but every application has its own instance).

Now, the solution I came up with so far is the following:

• Make the Singleton class a regular public class with an internal constructor (accessible only by classes of the same package).
• As with every product-oriented class, all static properties and static constants were moved to an internal SingletonShared class that will be passed as a parameter to the Singleton's constructor. Those two are hidden behind a public SingletonFactory, that has the static method getInstance(key).
• In case we're dealing with a more complex system, where each singleton requires it's own unique set of parameters, I added a static method of setAdapter(adapter) to the SingletonFactory. Using the method getShared(key), a class that implements ISingletonAdapter should return the SingletonShared value of that instance (e.g., SingletonXmlAdapter is passed an Xml file to the constructor, and deserializes a certain node based on the key it was given).

All of the above are packed as a Singleton package.

Now, for test-ability purposes, there is an option of marking Singleton as an internal class and have it implement an ISingleton public interface.

Questions:

1. Is this solution acceptable?
2. Is there a better / cleaner / shorter way of achieving the same effect?
3. Which version is best (Singleton as internal vs. constructor as internal)?

Thanks!

Answer 1

I think the solution you are describing as the SingletonFactoryis the ServiceLocator pattern and your Singletons are services.

Is this solution acceptable?

It depends on how and where you use the Singletons. Singletons are not bad in themselves, so long as you isolate the code that depends on them. Otherwise you end up injecting a bunch of complex Singletons every time you need a test fixture.

If you instantiate Singletons rather than using static getters/setters it will be more difficult to dependency inject without using a DI framework, unless you pass you singletons in, but then you can end up with a long list of parameters.

Is there a better / cleaner / shorter way of achieving the same effect?

IoC containers and DI frameworks (subtlety different) are often used to control dependencies that would otherwise be Singletons. However even if you eliminate the evils of Singletons, it is still good practice to try to isolate areas of dependency on particular services.