单例模式的替代方案？

Question

我正在尝试设计一种更灵活的单例模式。

我要解决的问题如下：

• 单例模式不能方便地进行测试。
• 它们滥用面向对象的方法，不允许继承，代码变得线性，很多开发人员倾向于过度使用它们。
• 它们仅限于一个实例，即在不复制类本身的情况下重复相同的机制（例如，ThreadPool作为每个应用程序的单例运行，但每个应用程序都有自己的实例）。

现在，我提出的解决方案如下：

• 将Singleton类作为常规公共类，具有内部构造函数（仅可由相同包中的类访问）。
• 与每个面向产品的类一样，所有静态属性和静态常量都移动到内部的SingletonShared类中，并将其作为参数传递给Singleton的构造函数。这两者隐藏在一个名为SingletonFactory的公共类后面，该类具有静态方法getInstance(key)。
• 如果我们处理的是需要其自己独特参数集的更复杂系统，则在SingletonFactory中添加了一个名为setAdapter(adapter)的静态方法。使用getShared(key)方法，实现ISingletonAdapter接口的类应返回该实例的SingletonShared值（例如，将Xml文件传递给SingletonXmlAdapter的构造函数，并根据其给定的键反序列化某个节点）。

所有上述内容都打包成一个Singleton包。

现在，为了进行测试，有一个将Singleton标记为内部类并使其实现公共接口ISingleton的选项。

问题：

1. 这个解决方案可行吗？
2. 是否有更好/更清晰/更短的方式来实现相同的效果？
3. 哪个版本最好（Singleton作为内部类还是构造函数作为内部类）？

谢谢！

- Moshe Bixenshpaner

---

你也可以在这里提出你的问题：http://codereview.stackexchange.com/ - JeremyFromEarth

Answer 1

我认为你所描述的解决方案是ServiceLocator模式，而你的单例是服务。

这个解决方案可行吗？

这取决于使用单例的方式和位置。单例本身并不是坏的，只要隔离依赖它们的代码即可。否则，每次需要测试夹具时都要注入一堆复杂的单例。如果您实例化单例而不是使用静态getter/setter，则在没有使用DI框架的情况下进行依赖项注入将更加困难，除非您传递单例，但这样可能会导致参数列表很长。

有更好 / 更干净 / 更短的方法来实现相同的效果吗？

IoC容器和DI框架（细微的区别）通常用于控制本来应该是单例的依赖关系。然而，即使消除了单例的弊端，尝试将特定服务的依赖关系隔离在某些区域仍然是良好的实践。

- Garrett Hall