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