问题描述
我见过一些人在评论中,辛格尔顿模式是反patest的.我想知道为什么?
推荐答案
测试
一个原因是单元测试不容易处理单例.您无法控制实例化,其本质可能会在召唤中保留状态.
因此,依赖注入的原理很受欢迎.每个类都注入(配置)与他们需要功能的类(而不是通过Singleton访问者得出),因此测试可以控制要使用的相关类实例(并在需要时提供模拟).
>诸如Spring之类的框架将控制其对象的生命周期并经常创建单例,但是这些对象通过框架注入其依赖对象.因此,代码库本身不会将对象视为单例.
例如.而不是(例如)
public class Portfolio { private Calculator calc = Calculator.getCalculator(); }
您将注入计算器:
public class Portfolio { public Portfolio(Calculator c) { this.calc = c; } }
因此,Portfolio对象不知道/关心存在多少个实例.测试可以注入一个虚拟Calculator,使测试变得容易.
并发
通过将自己限制为一个对象的一个实例,线程选项受到限制.可能必须访问单例对象(例如,通过同步).如果您可以维护这些对象的多个实例,则可以定制该实例,然后数量到您运行的线程,并增加代码库的并发功能.
其他推荐答案
我的个人看法是它违反了单一责任原则. Singleton对象既是其目的,也是控制他们认为错误的实例数量的原因.
这就是为什么许多人将控件委派给工厂对象的原因.
其他推荐答案
[可变] singleton是抗模式的反图案.
重要的潜在反图案是全球状态(或环境状态).借助全球状态,您将拥有一个跨程序的依赖性博客.这确实会影响测试,但这只是不良编程的影响的一部分.
在此层面上,Singleton在简单地宣布可变static字段的情况下添加了完全不必要的复杂性.
问题描述
I have seen some people in SO commenting that Singleton Pattern is an anti-pattern. I want to know why ?
推荐答案
Testing
One reason is that singletons aren't easy to handle with unit tests. You can't control the instantiation and by their very nature may retain state across invocations.
For that reason the principle of dependency injection is popular. Each class is injected (configured) with the classes they need to function (rather than derive via singleton accessors) and so tests can control which dependent class instances to use (and provide mocks if required).
Frameworks such as Spring will control the lifecycle of their objects and often create singletons, but these objects are injected into their dependent objects by the framework. Thus the codebase itself doesn't treat the objects as singletons.
e.g. rather than this (for example)
public class Portfolio { private Calculator calc = Calculator.getCalculator(); }
you would inject the calculator:
public class Portfolio { public Portfolio(Calculator c) { this.calc = c; } }
Thus the Portfolio object doesn't know/care about how many instances of the Calculator exist. Tests can inject a dummy Calculator that make testing easy.
Concurrency
By limiting yourself to one instance of an object, the options for threading are limited. Access to the singleton object may have to be guarded (e.g. via synchronisation). If you can maintain multiple instances of those objects, then you can tailor then number of instances to the threads you have running, and increase the concurrent capabilities of your codebase.
其他推荐答案
My personal opinion is that it violates the single responsibility principle. Singleton objects are responsible for both their purpose and controlling the number of instances they produce which I think is wrong.
This is why a lot of people delegate the control to a factory object.
其他推荐答案
[Mutable] Singleton is an anti-pattern of an anti-pattern.
The significant underlying anti-pattern is global state (or ambient state). With global state you have a big blog of dependency across your program. This does affect testing, but that's just a one part of the fallout from bad programming.
Layered upon that, Singleton adds completely unnecessary level of complexity over simply declaring mutable static fields.