Singleton and Static Utility classes [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, ov开发者_如何学Pythonerly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

What factors influence the appropriate design pattern to use?

Clarification:

The reason I ask this question is because I'm designing an application that requires multiple static factory classes and singleton manager classes. At times, I become confused as to which design I should employ and I thought asking this community why and when may help clarify things for me a bit.

---

Singleton is used when a single object needs to be instantiated and all requested object access goes through this particular instance. This object can maintain state if desired.

Static Utility is used when you have a class that is just stateless utility functions.. it does not maintain state. An instance of the object is never instantiated.

---

I use static utility classes for shared functions that will be called from many different contexts - e.g. maths functions similar to those in java.util.Math. This is an appropriate pattern assuming that these are "pure" functions (i.e. don't manipulate any state or access any data other than than the parameters they are given).

I very rarely use singletons, and in particular try to avoid global singletons. They suffer from all the usual problems associated with global variables. They make testing difficult, and unless your singleton is also immutable they introduce problems of global state. The main place I have found them useful is in performance hacks that depend on object identity - for example:

  public static final END_OF_SEQUENCE_MARKER=new EndMarker();

Then when traversing a sequence you can just test if (object==END_OF_SEQUENCE_MARKER). Because it's a static final reference, the JIT will turn this into an extremely fast test....

EDIT

Having just seen your clarification, some quick extra comments:

• Static factory classes don't usually make sense. The whole point of a factory class is that you can instantiate it (or a subclass!), make some configuration changes on the factory object, then use it to generate object instances according to the configuration that you need. If you're going to make it static, you might as well just create a static MyObject.create(..) method rather than having a whole static MyObjectFactory class....
• Likewise, why have a separate singleton manager class? Usually the best class to manage the singleton is the singleton class itself, since you will typically need it to access a private constructor, assuming you want to guarantee that only one instance will ever be created. Just having a simple static MySingleton.getInstance() method will usually do everything that you need.

---

IMO static utility classes chalk down a concrete contract between the caller and the class. This is different than singletons wherein you can change the implementation behind the scenes to make your so called 'singleton' provider hand out a new instance each time a call to getInstance is made.

So yes, basically use static utility methods when you are damn sure (e.g. Math) you'd never need an instance and use singletons when you think that a single instance is good enough for the time being but might change in the future (e.g. connection providers).

---

I'm not sure what the question is here.

Singleton patterns are used where the instance has state that may be preserved or altered across a number of calls - this might be a connection pool or some other shared object that the class provides access to.

Static utility classes are used where each individual method is stateless, and has no bearing on the other methods that the class provides.