关于oop：你怎么知道何时使用设计模式？

任何人都可以阅读GoF书籍以了解设计模式是什么以及如何使用它们，但是什么是确定设计模式何时解决问题的过程？ 模式的知识是否推动了设计，或者有没有办法弄清楚如何使用模式来改变设计？

换句话说，模式有模式吗？

我强烈推荐阅读O'Reilly的Head First Design Patterns。这解释了如何在现实世界中使用这些模式。

我还要补充一点，不要试图设计过多的图案。更多，寻找模式可能有助于解决的"代码味道"。

设计模式应该提供一个可以解决问题的结构。在解决实际问题时，您必须考虑解决该问题的许多微小变化，以确定是否符合设计模式。特别是，您可能需要概括您的问题或其解决方案，以使设计模式适合。

答案是，这是一门艺术。了解设计模式无疑是重要的一步。习惯这种事情的一种方法是研究设计模式的应用，而不仅仅是模式。查看一种模式的许多不同应用程序可以帮助您随着时间的推移更好地将任务映射到模式上。

大多数人都没有理解的基本模式的核心概念。不要将它们视为数据结构或算法。

相反，将您的代码视为发送消息的人，例如传递笔记??或发送信件。每个对象都是一个"人"。

您组织"人员"的方式以及他们用来向对方发??送消息的模式是模式。

把问题翻过来：你应该做的模式是"什么模式适合我的问题"。考虑一个非常简单的模式，在数组中查找元素。在C中，它就像是

你不看代码并想"我可以在哪里使用它"，你看看问题并说"我知道如何在数组中找到一个元素吗？"

更广泛的模式确实以同样的方式工作。您需要拥有许多不经常更改的数据结构副本 - 这会让您想到"Flyweight"。你想要一些生活在网络边界两侧的东西，你认为是代理。

当你研究模式，尤其是GoF时，问问自己"这种模式需要什么样的情况？我以前看过这种模式吗？我以前的工作中有什么用呢？我在哪里可以找到一个这样的例子？"

设计模式？你在浸泡它们！

设计模式没有什么特别之处，它们只是设计模式。所有开发都使用设计模式。在面向对象的编程中存在一组特定的设计模式，这些模式被认为是通常期望的并且已经成为规范的设计模式。但是也存在许多不期望的或其他无关紧要的设计模式(例如设计反模式)以及未发现和/或未记录的模式。

编程时无法避免使用模式。但是你可以更加了解你正在使用的模式，以及某些模式何时有用以及何时不可用。从GoF书中学习规范设计模式将有助于学习代码气味和重构。对于何时应该使用特定的设计或设计模式，没有一个正确的答案，您需要积累使用和实现它们的经验，以便知道何时何地使用哪种模式。

经验。了解其用途的模式和实际示例。每当您做出设计决策时，请考虑您知道的模式是否适用于它。随着时间的推移，您会变得更好，并且您会发现将模式应用于更广泛问题的新方法。

Rian van der Merwe在2012年6月为Smashing Magazine撰写了一篇很好的文章。这里有一些重要的要点。

设计模式有两个原因：

van der Merwe建议我们在以下情况下考虑打破模式：

我找到的另一本好书是：

重构模式

通过显示何时，何地以及如何将现有代码更改为模式，它使我对这些概念有了更好的理解，并且能够识别它们的使用位置。

如果您了解模式，那么它们就会成为工具箱中的工具。查看任务时，可以从工具中进行选择。那时你应该非常清楚哪个工具最适合给定的问题。这是公式停止工作的地方，你实际上是在做工程工作。

你是如何学习何时使用if语句的？

我把它比作它，因为它是一个更大的构造，你需要知道它的来龙去脉才能有效地使用它。 if语句解决了一类需要分支的问题。桥模式解决了一类问题。我真的不会以任何不同的方式看待它们。

设计模式的概念取自结构工程，与软件工程中的许多实践一样。如果您考虑构建结构，则需要就如何构建该结构以实现所设定的目标做出决策。在做出这些决定时，您将有一系列要求可供使用。它可能是一件简单的事情，因为Bridge必须能够同时支撑X吨，或者具有特定的抗拉强度以允许在风中进行足够的移动等。建筑师将使用其他构建的先验知识来做出这些设计选择。他/她不太可能尝试从头开始解决问题。

软件工程和设计模式完全相同。它们只是常见问题的常见解决方案。如果您了解设计模式，那么当您完成设计时，系统的特定部分需要适合您的设计模式，然后使用它。不要试图使系统适合设计模式，使设计模式适合您的系统(它们适合的地方)。只是尝试将它们视为一组解决方案，以减少您需要做的设计工作量，并谨慎地过度设计您的解决方案，尽可能多地填充设计模式。这只会使您的解决方案无法维护，而且可能非常多。

我第一次遇到设计模式时遇到了同样的问题。我很欣赏这些概念，但不知道何时或如何应用它们。我最初的方法是在设计阶段寻找适用性。一旦你有了每个区块的方框图和半清晰的责任，它就不太难以承担责任并用一本体面的参考书交叉引用它们。这里提到了几个好的，但GoF应该在你的名单上。下一步是根据您在模式中看到的内容寻找设计的改进。

我同意仅仅学习模式是不够的。大多数书籍的问题在于它们不提供真实的例子。我听说Head First Design Patterns，正如之前的一些建议，是一个很好的。

另一件事是，大多数书籍都是故意不是针对特定语言的，这对你来说既可能是好事也可能是坏事。无论如何重要的是要理解一般的模式，知道如何很好地实现它同样重要。我遇到过一本名为C＃3.0设计模式的书，它对这两个不可分割的方面都投入了相同的油墨。

设计模式是如何解决常见问题的一般描述。我们应该注意两件事：

首先，它是一个通用的描述;它不是具体的解决方案，也不是一个完整的配方，它只是描述解决方案如何处理常见问题。

其次，问题是问题是一个常见的问题：这意味着此问题之前已经多次遇到过，并且随着时间的推移，人们开始描述如何将理想的解决方案应用于这个通常重复的问题。

因此，如果您遇到一个不常见的新问题，请尽量不使用设计模式来解决它，或者至少不要将设计模式作为解决您遇到的任何问题的工具。