6 ms·

In case you are wondering why singleton's are bad practice in Java, here are two reasons off the top of my head. 1) Dependency hiding. Singletons are rarely b

• sebastianavina 15y ago
  thanks for your explanation. But, what is a singleton?
  • glassx 15y ago
    A quite good answer, from Wikipedia: "a design pattern [that restricts] the instantiation of a class to one object"
  • Tiomaidh 15y ago
    public class Singleton { private static Singleton self = null; private Singleton() { //... } public static Singleton getInstance() { if(self == null) { self = new Singleton(); } return self; } ... } So at any point in your code you can call Singleton.getInstance() to have access to the same Singleton object. So it's effectively the same thing as a global variable. Edit: Added `static' to be more correct.
    • billjedi 15y ago
      private Singleton self = null; is wrong. It has to be: private static Singleton self = null;
    • smanek 15y ago
      and that isn't thread safe lazy initialization either ;-) it's surprisingly tricky to get lazy init right.
    • qntm 15y ago
      What are the advantages of instantiating the Singleton object in multiple different locations rather than, for example, using the Singleton class itself as an object with various static attributes and methods?
      • MatthewPhillips 15y ago
        Not thread safe.
        • johnyzee 15y ago
          Thread safety is the same whether you use a static instance or plain static methods. In fact with all static members you don't have to worry about synchronizing initialization of the singleton object which is often done wrong. The only reason to use a singleton over static members is that it feels like OO. I suppose it also makes it easier to replace the singleton with a 'multiton' at some point in the future which somewhat justifies it.
          • MatthewPhillips 15y ago
            There isn't a clean way to initialize all of your static properties doing it that way. If you're using a language that has accessors you can call a private init method, but you have to do it for all of the properties. Or you can just use methods, but again you have to remember to call init at the beginning of them all. Or you could have a public init() and just remember to call it when your application first launches. Using a singleton is a natural way to have an entry point towards initialization. You can also have the best of both worlds by using static properties/methods that point to the singleton version. In Java/C# you can use a nested class to ensure thread safety and cheat towards having your static methods. For example: private int Foo() { } public static int Foo() { return _instance.Foo(); } private static FooBar _instance { return Nested.instance; } FooBar() { // Initialize here! } class Nested { static Nested() { } internal static readonly FooBar instance = new FooBar(); }
      • antrix 15y ago
        In addition to what johnyzee says, in Java at least, a class with just static methods can't _implement_ any Interfaces.
    • dteoh 15y ago
      Enum version: public enum Singleton { INSTANCE; } Guaranteed against multiple instantiation. Edit: the class version of the singleton example should also be made final, or I could just extend your class and therefore bypass your singleton restriction.
      • SoftwareMaven 15y ago
        Not with a private constructor.
• yuvadam 15y ago
  My gripe with global state (i.e. singletons) is not testability, maintainability nor correctness. It's nothing more than bad object-oriented design, or lack thereof. I've seen this time and again - even this week, as I am doing some major refactoring in old code - singletons are used exactly where someone was too lazy (or too busy) in order to do a proper design and review. I cannot count the number of proverbial SomethingManager singleton classes I've seen. At most, singletons should be used in a single point of entry to a module. From there on, even if other classes should be used once, their singularity will be derived from that single point of entry that contains them. Rule of thumb - stop using singletons. In 99% of the cases you will see a much better design exists.
  • jriddycuz 15y ago
    Isn't it bad design because it hinders testability, maintainability, and correctness? In general, whether we are talking about procedural, OO, functional, or whatever kind of programming, code is easier to reason about and test and use if the effects of its individual units (functions, classes, modules, &c.) depend largely on the inputs to them. In functional languages this is called "referential transparency," but its value applies to OOP as well. Using things like singletons creates hidden dependencies on things that can change over the lifetime of the program without those changes being made obvious to clients of that unit of code. Good design nails things down to explicit parameters.
  • Zak 15y ago
    Calling something bad design without discussing the actual problems it causes is mere name-calling or unsupported opinion. I submit that if you can't make a claim that something is hard to maintain, unreliable, hard to understand, incorrect, fragile, etc... then it is not bad design. The claim that it is "bad" because it doesn't fit in to a certain paradigm is at best a valid claim that it is inconsistent with the rest of the codebase and therefore hard to work with. At worst, it's cargo-cult engineering; doing something a certain way because it's said to be "good" without understanding why.
    • nostrademons 15y ago
• phillytom 15y ago
  Also most people forget that the typical approach to singletons can yield multiple instances if the application employs multiple classloaders.