This post originated from an RSS feed registered with Agile Buzz
by Dominik Wei-Fieg.
Original Post: Q: What is almost as bad as a Singleton?
Feed Title: Ars Subtilior
Feed URL: http://typo.ars-subtilior.com/articles.rss
Feed Description: Finest Handmade Code
Random thoughts about agile software development as an art
A: A class that has only static methods but also has (static) state.
In Java you often see XyzUtil or XyzHelper classes which only provide static methods (like, e.g., StringUtil from jakarta commons lang). These classes provide helper methods which usually act on an object which is passed along as an argument to the methods.
(Excursion: Java needs these static utilities because we can neither add new methods to a class without subclassing it and often cannot subclass the class we want to extend, like String, which is final. Ruby [and other languages] do not have this problem, since they provide the possibility to open a class and modify it or to use modules to mix in more behavior)
I don’t want to go into the question why I deem Singletons to be evil (I’m not the only one, just google for “Singleton evil”).
Now, a class which only has static methods and has a state is (imho) as bad as a Singleton, because it actually only is a Hidden Singleton, a way to work around the fact that the coding guidelines for a project don’t allow Singletons.
In the case I just stumbled upon such a hidden Singleton was used to retrieve a configuration object and to lazily create it, if it was not created before. So the first call to getConfiguration() created and stored (on a static field) a Configuration instance, and each further call just returned that instance. Now, first up, a getter should be idempotent anyway, but lets leave that aside. The class worked well in production settings. The first time the configuration was requested, it was created (which takes some time), afterwards the cached instance was returned. But during testing everything goes wrong. Using such a Hidden Singleton allows for the testing of only one Configuration. I can’t say: run this testcase with that configuration and this other testcase with that other configuration. The configuration was already loaded and won’t be modified.
So I either need a way to null the cached configuration on the Hidden Singleton, or need to get rid of it and replace it with some other pattern. What you usually want in such a setting is IoC, someone should simply set the configuration on all instances which need it (and such making those objects conform to the law of demeter, because they don’t need to fetch the Configuration from some other class). If you don’t have an IoC container, you might use a factory pattern to alleviate the pain the Hidden Singleton is causing. Use a factory to create the objects which need the Configuration. The factory can set the configuration on the objects during creation, and the configuration can be passed to the factory method (and, if really necessary, cached inside the factory until a different configuration is passed along…)
Previous Topic
