这个问题已经在这里有了答案:
已关闭8年。
可以理解，在某些情况下可能会滥用许多设计模式，就像妈妈总是说:“一件好事并不总是一件好事!”
我注意到这些天，我经常使用Singletons，我担心自己会滥用设计模式，并且越来越多地养成不良习惯。
我们正在开发一个Flex应用程序，该应用程序具有相当大的层次结构数据结构，当用户对其进行操作时会保留在内存中。用户可以按需加载，保存，更改和刷新数据。
这些数据通过Singleton类进行集中，该类聚集了一些ArrayCollections，Arrays，value对象以及一些通过getter和setter公开的其他本机成员变量。
为了从应用程序中的任何地方获取对我们数据的引用，我们对整个Model.getInstance()方法进行了处理，我确定每个人都熟悉。这确保了我们始终能够获得相同的数据副本，因为在设计时，我们曾说过在应用程序生存期内仅允许存在一个实例。
通过该中央数据存储库，例如，我们可以轻松地调度属性更改的事件，并且可以具有多个引用中央数据的UI组件，更新它们的显示以反射(reflect)发生的数据更改。
到目前为止，这种方法是有效的，并且已证明对我们的情况非常实用。
但是我发现，在创建新类时我有点过于渴望。诸如某个类应该是Singleton还是应该以其他方式进行管理(例如使用工厂)之类的问题有时会变得有些困难，并带有一些不确定性。
我在哪里画单例？是否有确定何时使用单例以及何时远离单例的良好指南。
另外，有人可以推荐一本关于设计模式的好书吗？
最佳答案
要记住的关键是设计模式仅仅是帮助您理解抽象概念的工具。一旦有了这种理解，就将自己专门局限于书中的“食谱”是没有意义的，并且会损害您编写最适合自己目的的代码的能力。
就是说，阅读GoF之类的书将为您提供更多思考问题的方法，以便当需要自己实现某些事情时，您将具有更广泛的视角来解决问题。
在您的情况下，如果在每种情况下使用单例都有意义，那么请继续。如果它“合适”并且您必须以笨拙的方式实现它，那么您需要提出一个新的解决方案。强制不完美的图案有点像在圆孔中锤击方形钉。
假设您说“这种方法很有效，并且证明对我们的情况非常实用”，我认为您做的还不错。
这是一些好书:
Gang of Four Book-设计模式的经典书
Head First Design Patterns-我听说有人建议这样做
关于design-patterns - 辛格尔顿真的那么糟糕吗？ ，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1020312/