【发布时间】：2010-09-10 06:14:55
【问题描述】：
任何人都可以阅读 GoF 的书来了解什么是设计模式以及如何使用它们，但是确定设计模式何时解决问题的过程是什么？模式知识是否驱动设计，或者有没有办法弄清楚如何使用模式来改变设计？
换句话说，Patterns 有模式吗？
【问题讨论】：
标签： design-patterns oop
【发布时间】：2010-09-10 06:14:55
【问题描述】：
我强烈推荐阅读 O'Reilly 的 Head First Design Patterns。这解释了如何在现实世界中使用这些模式。
我还要补充一点，不要尝试过多考虑模式的设计。此外，寻找模式可能有助于解决的“代码异味”。
【讨论】：
-
是的，我有那本书。真的很棒。我不在乎这些例子（鸭子和披萨之类的），但它为设计模式提供了坚实的基础。
-
但是本书中的例子（比萨、巧克力工厂等等）确实可以帮助你掌握每种模式的概念和想法。
-
感觉就像是把设计模式注入了大脑。真的是一本很棒的书。
经验。了解它们的使用模式和实际示例。每次你要做出设计决定时，想想你知道的模式是否适用于它。随着时间的推移，你会变得更好，你会发现将模式应用于更广泛的问题的新方法。
【讨论】：
-
学习如何识别设计模式的最佳场所之一是在 Coding Dojo 中，参与者可以在其中“刻意练习”玩具问题（参见 en.wikipedia.org/wiki/Kata_(programming) ）。本地用户组有时会托管 dojo。但是，即使一个人找不到道场可以加入，单独通过 katas 也有很多价值。
我发现的另一本好书是：
重构为模式
通过展示您可以在何时、何地以及如何将现有代码更改为模式，它让我对这些概念有了更好的理解，并且能够确定它们可以在哪里使用。
【讨论】：
您是如何了解何时使用 if 语句的？
我将其与此相提并论，因为它是一个更大的结构，您需要先了解它的来龙去脉，然后才能有效地使用它。 if 语句解决了一类需要分支的问题。桥接模式解决了一类问题。我真的没有任何不同的看法。
【讨论】：
设计模式应该提供一个结构在其中问题可以得到解决。在解决实际问题时，您必须考虑许多对该问题的解决方案的微小变化，以查看是否符合设计模式。特别是，您可能需要概括您的问题或其解决方案，以使设计模式适合。
答案是，这是一门艺术。 了解设计模式无疑是重要的一步。习惯这种事情的一种方法是研究设计模式的应用，而不仅仅是模式。随着时间的推移，了解一种模式的许多不同应用程序可以帮助您更好地将任务映射到模式。
【讨论】：
-
如何在没有文档记录的情况下研究不同的应用程序？在现实世界中，我们申请并继续前进。如何在申请前找到我们可以研究成功申请的来源？？？源头在哪里？？
-
给这个人一杯啤酒。
如果您了解这些模式，那么它们就会成为您工具箱中的工具。当您查看一项任务时，您可以从您的工具中进行选择。那时，您应该非常清楚哪种工具最适合给定问题。这就是公式停止工作的地方，而您实际上是在做工程工作。
【讨论】：
我同意仅仅学习模式是不够的。大多数书籍的问题在于它们没有提供真实世界的例子。我听说 Head First 设计模式，正如前面一些人所建议的那样，是一个很好的模式。
另一件事是，大多数书籍有意不是特定于语言的，这对您来说可能是好事也可能是坏事。无论总体上理解一个模式有多重要，了解如何很好地实现它也同样重要。我遇到了一本名为C# 3.0 Design Patterns 的书，它在这两个不可分割的方面都投入了几乎相同的墨水。
【讨论】：
当我第一次遇到设计模式时，我也有同样的问题。我很欣赏这些概念，但不知道何时或如何应用它们。我最初的方法是在设计阶段寻找适用性。一旦你有一个框图和每个块的半明确职责，承担职责并用一本像样的参考书交叉引用它们并不难。这里提到了几个不错的，但 GoF 应该在您的列表中。下一步是根据您在模式中看到的内容来寻找对设计的改进。
【讨论】：
设计模式？你沉浸在其中！
设计模式没有什么特别之处，它们只是设计模式。所有的开发都使用设计模式。面向对象编程中有一组设计模式被普遍认为是可取的，并已成为规范的设计模式。但也有许多不受欢迎或无关紧要的设计模式（例如design anti-patterns）以及未被发现和/或未记录的模式。
您在编程时无法避免使用模式。但是您可以更加了解您正在使用的模式以及某些模式何时有用，何时无用。从GoF book 学习规范设计模式会有所帮助，了解code smells and refactoring 也会有所帮助。对于何时应该使用特定的设计或设计模式，没有一个正确的答案，您需要积累使用和实施它们的经验，以便了解何时何地使用哪种模式。
【讨论】：
把问题转过来：你应该做的模式是“什么模式适合我的问题”。考虑一个非常简单的模式，在数组中查找元素。在 C 中，它类似于
TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ; // Your index variable
for(ix=0; ix < SIZE; ix++){
if (ary[ix] == item) {
return ix ;
}
}
您不会查看代码并思考“我可以在哪里使用它”，而是会看到问题并说“我知道如何在数组中查找元素吗？”
使用更广泛的模式实际上是相同的方式。您需要拥有许多不经常更改的数据结构的副本 --- 这让您认为是“享元”。你想要一些存在于网络边界两侧的东西，你认为是代理。
当你研究模式，尤其是 GoF 时，问问自己“什么情况下需要这种模式？我以前见过这种模式吗？我可以在以前的工作中使用它来做什么？我在哪里可以找到这方面的示例？自己的生活？”
【讨论】：
有一个核心概念是大多数人不理解的模式背后的核心概念。不要将它们视为数据结构或算法。
相反，您可以将您的代码视为人们相互发送消息，例如传递笔记或发送信件。每个对象都是一个“人”。
您组织“人”的方式以及他们用来相互发送消息的模式就是模式。
【讨论】：
与软件工程中的许多实践一样，设计模式的概念取自结构工程。如果您考虑构建一个结构，则需要就如何构建该结构以实现设定的目标做出决定。在做出这些决定时，您将有一组工作要求。它可能很简单，例如桥梁必须能够一次支撑 X 吨，或者具有特定的抗拉强度以允许在风中进行足够的运动等。建筑师将使用其他构建的先验知识来做出这些设计选择。他/她不太可能尝试从头开始解决问题。
软件工程和设计模式完全相同。它们只是常见问题的常见解决方案。如果您知道设计模式，那么当您完成设计时，系统的特定部分需要符合您拥有的设计模式的东西，然后使用它。不要试图让系统适应设计模式，让设计模式适应你的系统（它们适合的地方）。试着将它们视为一组解决方案，以减少您需要做的设计工作量，并小心过度设计您的解决方案以尽可能多地填充设计模式。这只会使您的解决方案无法维护并且可能非常有问题。
【讨论】：
Rian van der Merwe 在 2012 年 6 月为 Smashing Magazine 写了一封 excellent article。这里有一些要点。
设计模式之所以有用有两个原因：
- 模式可以节省时间，因为我们不必解决已经解决的问题。
- 模式使 Web 更易于使用，因为随着设计师采用的增加，用户习惯了事物的工作方式，这反过来又减少了他们在遇到常见设计元素时的认知负担。
van der Merwe 建议我们在以下情况下考虑打破模式：
- 新方法凭经验提高可用性，或
- 既定的方式变得过时了。
【讨论】：
-
这是一种不同的设计模式，但您的回答仍然很棒。 :)
设计模式是关于如何解决常见问题的通用描述。有两点需要注意：
首先，它是一个通用描述；这不是具体的解决方案，也不是完整的配方，它只是描述解决方案的外观以解决常见问题。
其次，问题是问题是一个常见的问题：，这意味着这个问题之前已经遇到过很多次，随着时间的推移，人们开发了一个描述理想的解决方案可以应用于这个经常重复的问题。
因此，如果您遇到一个不常见的新问题，请尽量不要使用设计模式来解决它，或者至少不要将设计模式用作解决您面临的任何类型问题的工具。
【讨论】：