Singleton模式的替代方案？

Question

我正在尝试设计一种更灵活的Singleton形式。

我想解决的问题如下：

• 单身人士不能轻易测试。
• 他们滥用面向对象的方法不允许继承，代码变得线性，许多开发人员倾向于过度使用它们。
• 它们仅限于一个实例，在复制相同机制而不复制类本身的意义上（例如，ThreadPool作为每个应用程序的单例操作的方式，但每个应用程序都有自己的实例）。

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

• 使Singleton类成为具有内部的常规公共类 构造函数（只能由同一个包的类访问）。
• 与每个面向产品的类一样，所有静态属性和 静态常量被移动到内部SingletonShared类 将作为参数传递给Singleton的构造函数。那些 两个隐藏在公共SingletonFactory后面，具有静态 方法getInstance(key)。
• 如果我们正在处理一个更复杂的系统，每个系统 单身人士需要它自己独特的参数集，我添加了一个 setAdapter(adapter)到SingletonFactory的静态方法。运用 方法getShared(key)，一个实现ISingletonAdapter的类 应该返回该实例的SingletonShared值（例如， SingletonXmlAdapter将Xml文件传递给构造函数，并且 根据给定的密钥对某个节点进行反序列化。

以上所有内容都打包为Singleton个包。

现在，出于测试能力的目的，可以选择将Singleton标记为内部类，并使其实现ISingleton公共接口。

问题：

1. 这个解决方案可以接受吗？
2. 是否有更好/更清洁/更短的方法来达到同样的效果？
3. 哪个版本最好（Singleton作为内部版，而构造函数作为内部版）？

谢谢！

Answer 1

我认为您描述为SingletonFactory的解决方案是ServiceLocator模式，而您的单身人士是服务。

  

这个解决方案可以接受吗？

取决于 如何和 您使用单身人士。单身人士本身并不坏，只要你孤立依赖他们的代码。否则，每次需要测试夹具时，最终会注入一堆复杂的Singletons。

如果你实例化Singletons而不是使用静态getter / setter，那么在不使用DI框架的情况下依赖注入会更加困难，除非你传递了单例，但最后你会得到一长串参数。

  

是否有更好/更清洁/更短的方法来达到同样的效果？

IoC containers和DI frameworks（微妙的不同）通常用于控制本来是单身人士的依赖关系。然而，即使你消除了Singletons的邪恶，尝试隔离对特定服务的依赖区域仍然是一种好习惯。