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