可能重复：单身人士有什么不好的？
可以理解的是，许多设计模式在某些情况下可能被滥用，就像妈妈总是说：“太多好事并不总是好的！”
我注意到这些天，我经常使用Singletons，而且我担心自己可能会滥用设计模式，并且越来越深入地研究一种不良习惯的习惯 .
我们正在开发一个Flex应用程序，当用户使用它时，该应用程序在内存中保留了相当大的分层数据结构 . 用户可以按需加载，保存，更改和刷新数据 .
这些数据通过Singleton类集中，该类聚合了几个ArrayCollections，Arrays，value对象以及通过getter和setter公开的一些其他本机成员变量 .
要从应用程序的任何位置获取对数据的引用，我们执行整个Model.getInstance（）方法类型的事情，我确信每个人都熟悉 . 这确保了我们始终掌握相同的数据副本，因为在我们设计时，我们说在应用程序生命周期中只允许存在一次实例 .
从这个中央数据存储库中，我们可以轻松地调度属性更改事件，并且可以有多个引用中央数据的UI组件，更新其显示以反映已发生的数据更改 .
到目前为止，这种方法已经有效并且证明对我们的环境非常实用 .
然而，我发现，在创建新课程时，我有点过分了 . 问题应该是一个类是Singleton，还是应该以其他方式管理，例如可能使用工厂，往往有点变得有点困难，有点不确定 .
我在哪里画单线？是否有一个很好的指导方针来决定何时使用单身人士以及何时远离他们 .
另外，有人可以推荐一本关于设计模式的好书吗？
12 回答
要记住的关键是设计模式只是帮助您理解抽象概念的工具 . 一旦掌握了这种理解，将自己专门限制在书中的“食谱”是毫无意义的，并且会损害您编写最适合您目的的代码的能力 .
也就是说，阅读像GoF这样的书会给你提供更多思考问题的方法，这样当你自己实现某些东西的时候，你将有更广泛的视角来解决问题 .
在你的情况下，如果在每种情况下使用单身人士都有意义，那么就去吧 . 如果它“适合”并且你必须以一种笨重的方式实现它，那么你需要提出一个新的解决方案 . 强制不完美的图案有点像在圆孔中敲击方形钉 .
鉴于你说“这种方法已经有效并且证明对我们的环境非常实用”，我认为你做得很好 .
这里有一些好书：
Gang of Four Book - 设计模式的经典书籍
Head First Design Patterns - 我听过几个人推荐的这个替代品
是的，单身人士很糟糕 . 它们很糟糕，因为它们为你所做的只是结合了两个属性，每个属性在95％的时间都是坏的 . （这意味着平均而言，单身人士在99.75％的时间里表现不佳;））
由GoF定义的单例是一种数据结构：
授予对象的全局访问权限
强制只能存在一个对象实例 .
第一个通常被认为是一件坏事 . 我们不喜欢全局变量 . 第二个是更微妙，但一般来说，实际上没有任何情况下这是一个合理的强制执行限制 .
有时，只有一个对象实例才有意义 . 在这种情况下，您选择只创建一个 . 您不需要单例来强制执行它 .
通常情况下，即使只有一个实例“有意义”，事实证明它根本没有意义 . 迟早，你需要不止一个 Logger . 或者多个数据库 . 或者您将不得不为每个单元测试重新创建资源，这意味着我们必须能够随意创建它们 . 在我们理解后果之前，它过早地从我们的代码中消除了灵活性 .
单身人士隐藏依赖关系并增加耦合（每个类都可能依赖于单例，这意味着除非我们还重用所有单例，否则该类不能在其他项目中重用），以及因为这些依赖项不是立即可见的（作为函数/构造函数参数），我们没有注意到它们，并且通常在创建它们时不会考虑它们 . 只需拉入一个单例就可以了，它几乎就像一个局部变量一样，所以我们倾向于在它们存在时使用它们很多 . 这使他们几乎不可能再次删除 . 你结束了，也许不是意大利面条代码，而是意大利面依赖图 . 迟早，你失控的依赖关系将意味着单身人士开始依赖彼此，然后在尝试初始化时获得循环依赖关系 .
他们使单元测试非常困难 . （如何测试在单个对象上调用函数的函数？我们不希望运行实际的单例代码，但是我们如何防止这种情况？
是的，单身人士很糟糕 .
有时，你真的想要全球化 . 然后使用全局而不是单身 .
有时，非常非常非常少，您可能会遇到这样的情况，即创建类的多个实例是一个错误，在不导致错误的情况下无法完成 . （关于我能想到的唯一一种情况，即使是设计的，如果你要将它映射到代码中的对象，那么只有一个实例可以存在才有意义） . 但是如果你发现自己处于这种情况（并且再一次，强调，多个实例导致严重错误的情况，而不仅仅是"I can't think of any use cases for more than one instance"的情况），那么强制执行该约束，但不要使对象全局可见 .
在极少数情况下，这两个属性中的每一个都很有用 . 但我想不出一个案例，他们的组合将是一件好事 .
不幸的是，很多人都认为"Singletons are OOP-compliant globals."不，他们不是 . 他们仍然遇到与全局相同的问题，引入其他一些完全不相关的问题 . 绝对没有理由比普通的全球更喜欢单身人士 .
软件开发人员似乎分成两个阵营，这取决于他们是赞成理想主义的编码风格还是实用的编码风格：
理想化：永远不要使用单身模式 .
务实：避免使用单例模式 .
就个人而言，我赞成务实的做法 . 有时违反规则是有道理的，但前提是你真正了解自己在做什么，并愿意接受相关的风险 . 如果您对以下关于特定用例的问题回答“是”，则单例模式可以产生一些实际好处 .
你的应用程序外部是单件吗？数据库，排队服务和ESB都是单例模式的完全有效的宏示例 .
KISS：你的整个应用仅限2-3个内部单身人士吗？
DRY：这些单身人士本身是否具有全球性，因此不得不将引用引入您应用中的几乎所有对象？ （例如， Logger 或组件介体）？
您的单身人士是否仅依赖于彼此和/或操作环境？
您是否确保了每个单例的正确启动和关闭顺序，包括内存管理注意事项？例如，一个"Grand Central"样式的线程池可能需要在main（）中使用实例Run（）和Shutdown（）方法，以便保证任务仅在它们操作的对象处于有效状态时运行 .
单身人士不会杀死程序，程序员会杀死程序 .
像任何编程结构一样，如果使用得当，你就不会在脚下射击 .
推荐的书很好，但是当你可以选择使用Singleton时，它们并不总能提供足够的经验 .
只有在你需要拥有多个实例的时候发现Singleton是一个糟糕的选择时才会出现这种体验，而且突然之间，你在各地注入对象引用时遇到了很多麻烦 .
有时最好继续使用对象引用，但是如果你必须将它重构为不同的设计，那么你使用Singleton的事实确实有助于确定你将遇到的问题的范围 . 我认为这是一件非常好的事情：即只有一个 class （即使设计不合理）能够提供一些能力来看到改变 class 的效果 .
我们已经开始了一个项目，我们基本上面对同样的问题，即如何 access the model ，特别是它的根元素 . 该项目不是Flex应用程序，而是一个游戏！卷筒纸应用程序，但这并不重要 .
在系统中有 single object unique 没问题，问题是 how to access it . 所以关于单身人士的辩论与 dependency injection （DI）的概念有关，以及如何获得对象 .
DI的主要论点如下：
可测试性和 Mock
将对象实例化与使用分离（可以导致生命周期管理）
关注点分离
DI的可能方法是（参见Fowler的经典article）：
在方法参数中传递对象
服务定位器
DI框架
在这种观点下，单例模式只是一种服务定位器，例如，
Model.getInstance().但是为了在面对未来的变化时提供最大的灵活性，对唯一对象的引用应该尽可能多_1195788_，并且仅在必要时使用
Model.getInstance()获得 . 这也将产生更清晰的代码 .在我看来，Singletons的使用直接表明了设计缺陷 . 原因很简单，它们允许人们绕过C中内置的正常对象创建和销毁机制 . 如果一个对象需要引用另一个对象，它应该在构造时传入对它的引用，或者在内部创建它的新实例 . 但是当你使用单例时，你明确地模糊了创建和拆除周期 . 一个相关的问题是控制单身人士的生命是极其困难的 . 结果，许多包括通用单例实现的包也包括笨重的对象生存期管理器等 . 有时候我想知道这些不存在仅仅是为了管理单身人士 .
基本上，如果您需要在许多地方使用对象，则应该在堆栈中的最高公共点处显式创建它，然后通过引用向下传递给使用它的每个人 . 有时候人们使用Singletons是因为他们在将多个args传递给新线程时遇到了问题，但是不要为此而明确定义你的线程args并以相同的方式将它们传递给新线程 . 您会发现您的程序流程更清晰，并且由于静态初始化依赖性或错误的拆卸而没有令人讨厌的意外 .
单身人士肯定不错 . 他们有自己的用途，其中一些非常好 . 单身人士确实倾向于被没有经验的开发人员过度使用，因为它通常是他们所了解的第一个设计模式，并且它相当简单，因此他们在不考虑其含义的情况下将它放在各处 .
每次要使用单例时，请尝试考虑为什么要这样做，以及使用此模式的好处和不利之处 .
单身人士确实有效地创建了一套全球可访问的“东西”（数据或方法），我想大多数人会同意使用太多的全局变量并不是一个好主意 . 类和面向对象的全部意义在于将事物分组为离散区域，而不是将所有东西都放入一个巨大的全局空间中 .
我发现我倾向于偏爱单身的“模式”之一是从顶部传递所需的对象 . 我在应用程序初始化阶段创建它们一次，并将它们传递给需要访问它们的所有对象 . 它模仿单身模式的“单一创造”部分，但没有“全局”部分 .
单身的全部意义在于它只适用于只存在1的物体 . 你提到了一组数据控件 . 也许考虑到实际上，有些情况下应用程序可能想要创建2组数据控件类，因此在这可能强制执行单例并不完全正确 . 相反，如果你在app init上创建了这些数据类并将它们传递下来，那么你只需要创建1套，因为这是你当前应用所需要的，但是你可以在某些时候开启，如果你需要第二套你可以轻松创建它们 . 此外，数据控制类应该可以从应用程序的任何位置访问全局 . 我认为不是，它们应该只能从较低级别的数据访问层访问 .
有些人推荐了GOF书 . 我会说，是的，这是一本很棒的书，但首先尝试先找一本关于通用架构的书，首先阅读2/3 / n层设计，封装，抽象和这些原则 . 这将为您提供一个更坚实的基础，以便了解GOF谈论的模式的适当用法 .
[编辑：单身变体的另一次可以有用的是当你想要一个单一的访问点时，但实现细节可能实际上不止一件事 . 调用者不需要知道，在封面下，他们对单例对象的请求实际上是针对几个可用对象解决的，并且返回了一个 . 我在想这里的线程池，使用的地方，嘿，只是给我一个线程，我需要1，但我不关心哪一个]
我知道这是一个老线程，但似乎没有人提到适合OP试图做的实际模式 . 我认为他所描述的需求被称为Mediator Pattern . SourceMaking是一个用于学习/参考此类信息的绝佳网站 . 绝对是我去向人们介绍软件模式的地方 . 而且，它只是学习何时何地使用它们才是诀窍 . 对我来说，从不使用单身人士的人不理解他们的用处 .
不，他们不一定是坏人 .
至于一本书，你需要从classics开始 .
单身人士并非“那么糟糕” . 如果您有很多相关的单身人士，并且您可以使用工厂替换/合并其中的一些，而不会丢失您关心的任何内容，那么您应该这样做 .
至于书籍，well, there's kind of a canon .
我以为singletons were good .
谷歌似乎是个不好主意的谷歌似乎是convinced .
这并不是说谷歌所做的一切都是完美的，或者说他们的每一种观点都是任何争论的结束，但是他们甚至已经写出了这个Singleton探测器来根除它们 . 你自有主张 .