32

In all my projects till now, I use to use singleton pattern to access Application configuration throughout the application. Lately I see lot of articles taking about not to use singleton pattern , because this pattern does not promote of testability also it hides the Component dependency. My question is what is the best way to store Application configuration, which is easily accessible throughout the application without passing the configuration object all over the application ?.

Thanks in Advance

Madhu

madhu
  • 497
  • 1
  • 6
  • 9

6 Answers6

26

I think an application configuration is an excellent use of the Singleton pattern. I tend to use it myself to prevent having to reread the configuration each time I want to access it and because I like to have the configuration be strongly typed (i.e, not have to convert non-string values each time). I usually build in some backdoor methods to my Singleton to support testability -- i.e., the ability to inject an XML configuration so I can set it in my test and the ability to destroy the Singleton so that it gets recreated when needed. Typically these are private methods that I access via reflection so that they are hidden from the public interface.

EDIT We live and learn. While I think application configuration is one of the few places to use a Singleton, I don't do this any more. Typically, now, I will create an interface and a standard class implementation using static, Lazy<T> backing fields for the configuration properties. This allows me to have the "initialize once" behavior for each property with a better design for testability.

tvanfosson
  • 524,688
  • 99
  • 697
  • 795
  • 4
    +1, people DO love to create their little rules like "only one exit from a loop" or "no singletons allowed". I'd prefer to be pragmatic rather than dogmatic since dogma leads to people not being able to think for themselves. If you can only have one X object, you should only have one XConfig object. – paxdiablo Dec 17 '08 at 04:38
  • 2
    Having a single instance of a configuration object is fine and desirable, but it doesn't make using a Singleton to get it good. Using hacks like test specific methods in your actual class aren't good for clean code or tests either. – ColinD Dec 18 '08 at 22:37
  • 4
    Do you have an example of the new "implementation" with an interface and a standard class using static? – Gabrielizalo Jul 19 '18 at 14:09
  • 6
    @tvanfosson better if you and include the new example here. I didn't get it. – s1n7ax Nov 03 '20 at 08:06
5

Use dependency injection to inject the single configuration object into any classes that need it. This way you can use a mock configuration for testing or whatever you want... you're not explicitly going out and getting something that needs to be initialized with configuration files. With dependency injection, you are not passing the object around either.

ColinD
  • 108,630
  • 30
  • 201
  • 202
  • 1
    So in this case the configuration object will be still a singleton, but the code will use an interface, instead of directly the class, and the actual implementation will be injected by Spring? So we could inject a mock object for testing. Is this correct? – stivlo May 28 '11 at 18:23
  • @stivlo: Right, the single instance would be managed by the dependency injection container (be that Spring, Guice or whatever) and the code could use an interface perhaps, allowing you to pass in an implementation you make with the settings you want for testing. It doesn't necessarily have to be a mock... it could be the real implementation, just with settings you add yourself instead of reading from a file. – ColinD May 28 '11 at 23:09
  • So, @ColinD, please bear with me, the whole focus here is not that Singleton is bad for itself, it could be appropriate, especially for application configuration or maybe to maintain a pool of connections I would say, but it can become bad when the dependency is hidden, so we don't see the code dependencies. Setting this dependency with a dependency injection container, makes it explicit. This kind of conclusion is a little different from "avoid singletons" dogma, would you agree with it? – stivlo May 29 '11 at 01:15
  • @stivlo: When I say "singleton" I'm referring to a single instance of a particular class in an application and not to the Singleton design pattern (that uses a static instance of the class). The Singleton design pattern is what the dogma is about, though singletons in general are probably overused when a finer scope would be better. As far has making the dependency explicit vs. hidden: yes, that is one of several good reasons to use dependency injection rather than the Singleton pattern. – ColinD May 29 '11 at 01:26
1

For that specific situation I would create one configuration object and pass it around to those who need it.

Since it is the configuration it should be used only in certain parts of the app and not necessarily should be Omnipresent.

However if you haven't had problems using them, and don't want to test it that hard, you should keep going as you did until today.

Read the discussion about why are they considered harmful. I think most of the problems come when a lot of resources are being held by the singleton.

For the app configuration I think it would be safe to keep it like it is.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
OscarRyz
  • 196,001
  • 113
  • 385
  • 569
0

The singleton pattern seems to be the way to go. Here's a Setting class that I wrote that works well for me.

Community
  • 1
  • 1
Protagonist
  • 1,121
  • 1
  • 8
  • 12
0

If any component relies on configuration that can be changed at runtime (for example theme support for widgets), you need to provide some callback or signaling mechanism to notify about the changed config. That's why it is not enough to pass only the needed parameters to the component at creation time (like color). You also need to provide access to the config from inside of the component (pass complete config to component), or make a component factory that stores references to the config and all its created components so it can eventually apply the changes.

The former has the big downside that it clutters the constructors or blows up the interface, though it is maybe fastest for prototyping. If you take the "Law of Demeter" into account this is a big no because it violates encapsulation. The latter has the advantage that components keep their specific interface where components only take what they need, and as a bonus gives you a central place for refactoring (the factory). In the long run code maintenance will likely benefit from the factory pattern.

Also, even if the factory was a singleton, it would likely be used in far fewer places than a configuration singleton would have been.

user2366975
  • 4,350
  • 9
  • 47
  • 87
-1

Here is an example done using Castale.Core >> DictionaryAdapter and StructureMap

ruslander
  • 3,815
  • 4
  • 32
  • 34