Question

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.

Answer 1

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.