设计模式 [重复]答案

【问题标题】：Design Patterns [duplicate]设计模式 [重复]
【发布时间】：2009-06-14 01:41:11
【问题描述】：

可能重复：
How do you know when to use design patterns?

我如何理解/决定“何时使用什么设计模式”？

在决定在适当的地方使用适当的设计模式时要注意哪些因素？

【问题讨论】：

【解决方案1】：

一般来说，如果你做得对，就会有一个模式。您现在可能知道您正在使用它。

如果你做错了，有一个反模式。但是你肯定不知道你在使用它。

【讨论】：

【解决方案2】：

Gang of Four (GoF) 模式是一个很好的资源。

【讨论】：

GoF 网站上的讨论非常抽象。我发现它们很难理解。
任何关于设计模式的讨论都是抽象的。这是一个适用于大多数语言的非常高级的概念。 Steve 提供的链接的好处在于，对于每种模式，您都会获得一个带有真实代码的真实世界示例。您应该能够从这些示例中找出真正的应用程序。

【解决方案3】：

您不应该总是着手使您的软件符合一种设计模式，但如果它与一种设计模式相匹配，您就可以使用它。在许多情况下，您所做的大多数事情都会有一个设计模式，它只是从许多不同的软件实现中观察到的一种常见模式。

例如，如果您有一组类都需要同步。好吧，这适用于观察者或发布/订阅模式，其中一个类是通知者，另一个类是监听通知。 Observer pattern

或者说你想限制游戏引擎中的内存使用，那么你可以创建一个 ObjectPool。 Object pool

或者，也许您想将一组对象简化为一个简单的 API，然后使用 Facade 模式：Facade pattern

很多时候只使用封装或继承等功能模式就可以了。这取决于问题。在大多数情况下，您尝试编写的大部分代码都将在模式中得到解决，但模式并不是唯一的编码方式。在许多情况下，您开始设计或有需求，它就变成了一种模式。

记住模式源于对多种软件问题的观察，它不是起点，而是软件架构的反映。

dofactory.com 上的许多模式示例：Design pattern tutorial by dofactory

强制设计模式就像强制 OO。它应该来自手头项目的需求。

【讨论】：

【解决方案4】：

所有定义明确的模式都有背景、上下文和模式解决的问题。

模式的全部意义在于告诉你什么时候合适。

【讨论】：

【解决方案5】：

查看优秀的书籍"Emergent Design: The Evolutionary Nature of Professional Software Development"。它向您展示了我们如何最终形成设计模式，并将为您提供有关构建代码的良好指导。

【讨论】：

【解决方案6】：

我发现如果我只是在 hack 一个程序，几乎不可能很好地使用设计模式，但是，如果你设计你的程序，那么你可以看看你想要做什么，并且设计模式开始出现在你的申请。

例如，如果您看到有一个类可以指导应用程序的流程，那么控制器模式就有意义。

使用设计模式的另一种方法是编写程序，使其工作，然后使用设计模式进行重构。我相信 Martin Fowler 写了一本关于这个主题的书，但我对作者并不持肯定态度。

无论哪种方式，了解您想要做什么来帮助决定哪种模式最有效。

【讨论】：