Design patterns 单身真的那么糟糕吗？

可能重复：

可以理解的是，许多设计模式在某些情况下会被滥用，就像妈妈经常说的：“太多的好东西并不总是好的！”

我注意到这些天来，我经常使用单例，我担心我自己可能会滥用设计模式，并越来越深地陷入一种坏习惯

我们正在开发一个Flex应用程序，当用户使用它时，它有一个相当大的层次数据结构保存在内存中。用户可以根据需要加载、保存、更改和刷新数据

该数据通过单例类集中，该类聚合了两个ArrayCollection、数组、值对象和一些其他通过getter和setter公开的本机成员变量

为了从应用程序中的任何地方获取对数据的引用，我们使用了整个Model.getInstance（）方法类型，我相信大家都很熟悉。这确保了我们始终能够获得相同的数据副本，因为在设计时，我们说过在应用程序生命周期中只允许存在一个实例

从这个中央数据存储库中，我们可以很容易地调度属性更改事件，并且可以有多个UI组件引用中央数据，更新其显示以反映已发生的数据更改

到目前为止，这种方法是有效的，并证明对我们的情况非常实际

然而，我发现我在创建新类时有点过于热情了。像类应该是一个单独的类，还是应该以其他方式进行管理，比如可能使用工厂之类的问题，有时会变得有点困难，带有一些不确定性

我该在哪里与单身人士划清界限？是否有一个很好的指导方针来决定何时使用单例以及何时远离单例

---

另外，有人能推荐一本关于设计模式的好书吗？

不，它们不一定不好

---

对于一本书，您需要从开始。

要记住的关键是，设计模式只是帮助您理解抽象概念的工具。一旦你有了这样的理解，把自己限制在一本书中的“食谱”是毫无意义的，并且会损害你编写最适合你的代码的能力

这就是说，阅读像GoF这样的书会给你提供更多思考问题的方法，这样当你自己实施某件事情的时候，你会有更广泛的视角来解决问题

在您的情况下，如果在每种情况下都使用单例是有意义的，那么请继续。如果它“有点”合适，并且您必须以某种笨拙的方式实现它，那么您需要想出一个新的解决方案。强迫一个不完美的图案有点像在圆孔中敲打一个方形的钉子

考虑到你说“这种方法是有效的，并且在我们的情况下被证明是非常实用的”，我认为你做得很好

以下是一些好书：

-设计模式的经典书籍

-我听一些人推荐这一点作为替代

单身人士并没有“那么糟糕”。如果您有很多相关的单例，并且您可以使用工厂替换/整合其中的许多单例，而不会丢失任何您关心的东西，那么您应该这样做

---

至于书籍，我想。

单身汉不会杀死程序，程序员会杀死程序

与任何编程构造一样，如果使用得当，您不会自食其果

推荐的书很好，但它们并不总是提供足够的背景知识，让你在选择使用Singleton时有足够的经验

只有当您发现当需要多个实例时，单例是一个糟糕的选择时，这种体验才会出现。突然之间，您在到处注入对象引用时遇到了很多麻烦

---

有时，最好是继续进行并将对象引用放在适当的位置，但事实上，您使用的是Singleton，这确实有助于确定如果您必须将其重构为不同的设计，您将面临的问题的范围。我认为这是一件非常好的事情：即仅仅拥有一个类（即使设计得很糟糕）就可以让我们看到类的变化所带来的影响。

单例当然不坏。它们有它们的用途，其中一些很好。没有经验的开发人员往往会过度使用单例，因为这通常是他们了解的第一个设计模式，而且非常简单，所以他们会到处乱扔，而不考虑其含义

每次你想使用一个单体，试着考虑你为什么要这么做，使用这个模式的好处和缺点是什么。

单例确实有效地创建了一组全局可访问的“东西”（数据或方法），我想大多数人都会同意使用太多全局变量不是一个好主意。类和面向对象的全部意义在于将事物分组到离散的区域，而不是将所有事物都放到一个巨大的全局空间中

我发现我比单例更喜欢的一种“模式”是从顶部向下传递所需的对象。在我的应用程序初始化阶段，我创建了一次，并通过需要访问它们的所有对象传递它们。它模仿单一模式的“单一创建”部分，但没有“全局”部分

单例的全部意义在于，它适用于只应存在1的对象。您提到了一组类的数据控制。也许考虑到，事实上，有些应用程序可能想要创建2套数据控制类，所以也许强制执行这一点不是完全正确的。相反，如果您在appinit上创建了这些数据类，并将它们向下传递，那么您将仅