不恰当的对象获取方式

    不必要的Singleton模式。如果一个对象本身没有内部状态，只是根据外界状态进行计算，这样的对象不需要是Singleton的。例如CommonTool类和SessionService类：这两个类只是把请求转发给其他对象处理，它们不需要使用Singleton模式。

    通过其他对象获取。从其它对象中取出自己需要的依赖对象，“由谁提供某个对象”的决策相当随机，有时通过一条长链来获得自己真正需要的依赖对象。例如要得到RightPaneXMLParser对象，就需要通过下列方式：  

    重构办法：

    如前所述，对象所需的依赖对象全部以构造函数参数的形式获得，将“创建对象”的责任不断上推，直至系统顶端的某个位置聚集了系统中绝大部分的对象创建逻辑。

    在系统顶端分离出一个全局工厂对象，该对象负责创建系统中所有的对象，并组装对象之间的依赖关系。其他地方原则上不作对象创建。

    在少数不直接被这个系统顶端调用的地方（例如对外暴露给第三方的接口），从全局工厂请求自己需要的对象。

    引入轻量级IoC容器（建议在PicoContainer和Spring Core之间选择），替代这个全局工厂对象。

    重构目标：

    系统中主要业务对象的创建都在全局工厂进行。

    业务对象是否Singleton能够以配置的方式管理。