Why do people prefer to have singleton class(class with private class) to read the property file/logging. Why not the static method in a class. What is the drawback of doing the samething using the static method of a class rather than creating just one instance of a class.
Whether to use a static class or a singleton is the kind of question that will bring geeks to blows as quickly as where to put curly braces.
FWIW, here are the tradeoffs I can think of offhand:
1.) initialization - a singleton can be initialized in the factory method, which may throw exceptions. While exceptions from constructors are allowed they are sorta' frowned on.
A static class can be initialized in a static constructor but when that gets called is less defined than the singleton factory and exceptions will end up as ExceptionInInitializer
2.) intent - a Singleton is probably the most common pattern and maintainers should know what the original developer intended when they see one
3.) the static class should have a private final constructor that will never get called (doesn't hurt anything, just useless code)
4.) syntax - pretty obvious but the syntax of a static method call is cleaner than calling the singleton factory and then the method
I suspect that the initialization is the primary reason you'd see singletons used for property file access.
- no instance needed so a little less memory usage.
- you can't use it anywhere an instance is needed.
- you can't extend any abstract class with abstract methods because you need an instance to use these methods.
- you are limited to only one single "instance" for life. If you ever need more "singleton" instances you have to rewrite code.
Singletons: well, switch around the pros and cons of static methods. The getInstance() method can be rewritten to return one of several instances; check out Multiton in this thread.
String.CASE_INSENSITIVE_ORDER is an example of the first pro for singleton; it implements Comparator<String>, so you can use it anywhere a Comparator is needed, like in TreeSet, TreeMap, Collections.sort, etc.
The second pro is something I've used quite a bit in my recent work projects. Summarizing:
The BaseClass provides the actual code, but some values are specific to sub classes. These values are provided by sub classes. But each sub class instance should only have one instance, so they become singletons. I can then use it:
It is possible to create partially constructed instances of derived classes if the base class constructor throws an exception.
Do a search for java constructor throwing exceptions for examples.
I said "frowned upon" and not forbidden or prohibited because this is a coding practice that may cause subtle bugs.
Another advantage of a singleton is that if you're programming to an interface you can have the singleton implement the interface. You can't do that with static methods. This can make it possible, for instance, to replace the instance with a mock object to break the dependency during unittesting.
On the other hand, if you're really bothered about that, you're probably better off using a factory pattern instead. The factory can always return the same object if you want, giving you a de facto singleton, but you've got more flexibility.
This article ExceptionsInConstructors has a couple of reasons why I would not (in general) throw an exception from a constructor. In particular the reasons are inaccessibility of resources created in a constructor and a potential security issue with partially constructed objects.
Just to be really clear though, I am not suggesting that this is a strictly forbidden practice but one that should be used with an understanding and acknowledgement of the potential issues.