开发者

Proper singleton design? [duplicate]

This question already has answers here: Closed 11 years ago.

Possible Duplicate:

Efficient way to implement singleton pattern in Java

I have a singleton class that acts as a state saver 开发者_开发百科for my application. For instance if I have a view that has some data, I just pacakge the data to a saved state serializable object and pass it to my singleton for retrival later. This all seems natural and proper, but I have deviated from the singleton example on Wiki. Intead of having a get instance method that will let me retrieve the instance and call methods though the instance, I instead just set every method to static and use the class statically.

Is this bad form? Is there a performance lose?

Thanks for any tips ~Aedon


If static use fulfills your needs, I don't see any evil in it.

The only downside is that it's slightly less flexible. If you designed it as an actual singleton, you could have an interface for managing state, and instantiate a particular implementation for a specific situation. This object could then be passed into your application as an argument.

Using a strictly static class, there's not object to pass, so you'd have to resort to passing around Class objects and accessing the functions through that interface.

Of course, all of that only matters if there's any chance this would ever expand beyond the reasonable capabilities of your current class.


Yes, it is considered bad form.

Static classes in Java have a number of problems that make them difficult to work with. For example, you can't implement an interface. Also, if you ever need to make it a regular Singleton again -- or need to make it a non-Singleton, which happens quite often -- you'll have to rewrite every line of code that interacted with it.


Yes, using only static methods and variables is not the object oriented way. Singletons are mostly considered a bad practice. However, I admit they are very useful sometimes. Here is a simple example of how to create a valid and functional Singleton class. Note that there are other ways too, but this is one of the most common...

public class Singleton {
   private static final Singleton uniqueInstance;

   public static synchronized Singleton getInstance() {
     if (Singleton.uniqueInstance == null) {
       Singleton.uniqueInstance = new Singleton();
     }
     return Singleton.uniqueInstance;
   }

   //other methods go here...

   @Override
   protected Singleton clone() throws CloneNotSupportedException() {
     throw new CloneNotSupporedException("cloning of singleton is not supported");
   }

   //hide constructor for others to see
   private Singleton() {
   }
}

cheers, P


Use Enum instead of Singleton. It's the safest way.


It is considered bad form because it's not object-oriented style. Many consider singletons poor form anyway. Frankly, it'll work just fine for what you're trying to do. Unless you're going to present this for review or evaluation I'd leave it alone.

Performance will likely be better as a static class.


Add to @Boris' comment, if all you need is a Utility class its is even simpler using an enum

public enum Utility {
    ; // no instances
    public static Object myStaticMethod(Object ... args) { }
}

If you have an interface to implement, this a singleton makes sense. Note, you can create more than one Singleton with an enum

public enum Callables implements Callable<String> {
    HELLO {
         public String call() { return "Hello"; }
    }, 
    WORLD {
         public String call() { return "World"; }
    }
}

Note: HELLO and WORLD share a super class Callables but actually have different classes.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜