单身人和静态实用类[英] Singleton and Static Utility classes





我问这个问题的原因是因为我正在设计一个需要多个静态工厂类和Singleton Manager类的应用程序.有时,我对我应该采用哪种设计感到困惑,我想问这个社区为什么和何时可能会为我澄清一下.


i使用静态实用程序类作为共享功能,这些功能将从许多不同的上下文中调用 - 例如.数学功能与java.util.math中的数学相似.这是一个合适的模式,假设它们是"纯"函数(即,除了给出的参数外,没有操纵任何状态或访问其他数据).


  public static final END_OF_SEQUENCE_MARKER=new EndMarker();

然后,在遍历序列时,您可以测试IF(object == end_of_secorence_marker).因为这是静态的最终参考,所以JIT将其变成非常快速的测试.



  • 静态工厂课程通常没有意义.工厂类的全部要点是,您可以实例化(或子类!),对出厂对象进行一些配置更改,然后根据所需的配置使用它来生成对象实例.如果您要使它静态,那么您不妨创建一个static myobject.treate(..)方法,而不是拥有整个静态myobjectFactory类....
  • 同样,为什么要有单独的Singleton Manager班?通常,管理Singleton的最好的类是Singleton类本身,因为您通常需要它访问私有构造函数,假设您要保证只会创建一个实例.仅具有简单的静态mysingleton.getInstance()方法通常会完成您需要的一切.









What factors influence the appropriate design pattern to use?


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.


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....


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.


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.


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).