Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In applications that I write at work, I often need to have an external properties/settings file so that certain parameters can be configurable after the application is deployed with the end-user. The file will usually be text or XML and I will usually be implementing in C++ or Java.

In the past, I have created Singleton classes to manage the injection of these properties/settings into my application. The class would be initialised with the path to a file, be hardcoded with the property keys it is looking for in the file, read it in and store all the attributes. Other classes in the application would then perform a call such as propertySingleton::getInstance().getMyParameter().

The more I read and learn about software engineering, and design, the more this approach feels clumsy and inherently wrong. I was wondering if anyone had to perform similar tasks, and how they would approach this in a well-thought object-oriented fashion?

share|improve this question

Your singleton approach is quite good if:

  • you don't look up the configuration with an absolute path (using a relative path, or even better a class path you should be fine)
  • if you don't reinvent the wheel, and in Java you use an API for loading the properties such as the JDK Properties or Apache's powerful PropertyConfiguration

Also, a much better solution, if you are using an IOC framework such as Spring for example, as suggested by Ankit, then using the PropertyPlaceholderConfigurer is really a nice option since you just need to configure this singleton bean and you don't need to write any code.

share|improve this answer
+1 for recommending existing possibly reusable solutions. – John Tobler Sep 9 '11 at 19:43

a singleton is an appropriate use for a global service; i see nothing wrong with this approach

share|improve this answer

Having your objects 'call out' to a static singleton to get settings creates a dependency. It is no better than the 'service locator' anti-pattern.

I would invert that dependency by making the settings constructor parameters/properties, and having my IOC container supply them. That way the only thing that is explicitly dependent on "settings" is the object responsible for construction.

Most IOC containers provide the ability to configure dependencies using XML, so this might serve as a better configuration system. I use Autofac and a custom solution here:

share|improve this answer

I think something like Spring PropertyPlaceHolderConfigurer or an extension of it may be handy in such cases. Where on one side you don't make your class Singleton and it allows your class to be properly tested.

And on the other side, you mark your bean to be a singleton so that there will be only one instance of it at a time in the system.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.