因此，背对背问两个问题有点奇怪，但是它们并不太相关，我也不想将它们结合在一起，但是我保证，我不是在发垃圾邮件！

无论如何，我是一个刚上大学的应届毕业生，我的学业只涉及设计模式...我们实施了一些简单的模式，涉及了更复杂的事实，并被告知如果我们去GoF书，想了解更多。我的问题是，值得学习GoF书中的模式吗？在我看来，尝试使问题适合经典模式似乎总是违反直觉的，但是很显然，这本书和这些模式都是有名的。它们显示出来足以让我学习吗？

再次感谢！

照常

这取决于

这取决于您是否能够识别甚至能够利用设计模式进行了多少次面向对象操作

这取决于您的纪律性，是否一旦正确学习就将运用这些模式，而不是像锤子一样发疯

另一方面...五个手指！

如果您已经完成了几年认真的OOP工作，或者您有一位可靠的导师让您始终处于正常状态，或者您就像OOP书呆子阅读一样，那么一定要去买书并研究一下。

有助于了解模式，以便您识别何时使用它们以及何时不使用它们。

是的，您应该学习它们。

在您获得一些经验之后，重新访问它们变得更加有意义，以便您可以将它们与您所了解的进行比较。对于某些模式，事实证明这是您自己发现的，但是您将学到一些更常规的用法，权衡，变体等。其他人似乎可以直接解决您要解决的问题，并向您展示您不知道的优雅解决方案。

大多数的模式是非常有用的和常见的。其他人可能不那么受欢迎，但是在它们非常适合的地方仍然有一些狭窄的用法。

值得一读的另一个原因是：它将教您如何思考。当然，这不是灵丹妙药，但仍然是无价之宝。

最后但并非最不重要的一点是，永远不要在任何情况下尝试使问题适合某种模式或工具。那是非常糟糕和危险的想法！了解该工具的工作原理，并明智地使用它来解决问题，反之则不行。

您了解的工具越多越好。有时，一种工具可以激发您的思维（而不是直接解决问题），而有时，您将其中的一些结合起来可以提供一个很好的解决方案。

GOF书是我们每天使用的许多有用工具的重要来源。

稍微了解一下设计模式，最重要的好处就是您知道这些术语的含义。换句话说，您知道普通词汇。

对我来说，这是所有设计模式动荡中最重要的成就，它产生了一个通用词汇，您可以在其中使用特定模式的名称，而其他人则立即知道您在说什么而无需解释它。模式描述的内容对于大多数程序员来说都是众所周知的，但是花时间向其他人解释您的意思，因此使交流更容易了解模式名称。

示例包括“访客”，“单例”和“装饰器”。

因此，换句话说，我建议您至少熟悉名称及其作用。

是的，但要谨慎！

是的部分：

有时，我们在设计中遇到问题。有时，这些问题很常见，因此设计模式可为您提供经过良好测试的解决方案。学习设计模式的主要好处是您可以更快地提出设计解决方案，并且如果您的同事知道设计模式的术语，那么您也可以更快地解释解决方案。

谨慎部分：

设计模式不应成为解决方案的圣杯。人们更希望使用最简单的（KISS）解决方案，并且很多时候设计模式会使事情变得更复杂。如果您正在学习设计模式，还请学习反模式。我认识一些反对设计模式的老人们，我确实在某种程度上同意他们的看法，因为如果您没有太多的编码经验，但是在设计模式理论方面有很多负担，您可能最终会使您和您的产品变得更薄球队。

最后，不要认为仅为了符合设计模式就必须安装/更改解决方案。相反，您可以弯曲设计模式，使其适合您的解决方案。如果您没有使用设计模式配方的所有成分，也可以，只要您有针对特定问题的更好解决方案即可。将设计模式视为一种建议，而不是解决方案的规则。

我发现Net Objectives思考模式的方法是最有益的。人们在阅读GoF书籍时常常开始假设它们以设计符号和代码显示的结构就是模式，而这始终是他们的外观。有一种不同的，可以说是更好的方式来查看它。

模式是一组可以用某些抽象公式解决的类似问题，而不是可用于解决各种问题的一组公式。这意味着在您甚至开始尝试进行设计之前，该模式就已经存在，设计人员的目标是找到它，而不是强加它。

而且，很多人看着模式，然后说：“哦，我只是通过...解决了这个。我没有使用任何愚蠢的模式。” 问题是，“ ....”几乎不可避免地描述了给定模式解决方案的AN实现。例如，即使这不是传统配方的样子，功能指针数组也可以充当责任链。

考虑到这一点，您在模式研究中的重点应该放在问题上，而不是模式上。了解模式的激励因素以及它们如何解决这些因素。这样做可以让您查看问题的模式，然后简单地指出它们。这以及模式为我们提供有关设计的语言，使您可以揭露非常适合解决当前面临的各种困难的设计。

是的，简而言之，学习模式不仅非常值得……您可以通过不学习来限制自己。当我说“看起来像我的访客”时，我不想描述所有激励性原则和解决方案的一般形式。

这是他们的网站：http : //www.netobjectives.com/PatternRepository/index.php?title=Main_Page

GoF描述的设计模式是OO范式的自然扩展。如果您不完全了解OOP的目标（封装，关注点分离，DRY原理，模块化等），那么尝试成功应用设计模式就没有多大意义。

但是，如果您陷入现实的OOP中并尝试忠实于OOP值，那么您将不可避免地陷入GoF所描述的情况，并且您很有可能会发明与之类似的解决方案。解决了许多类似的问题后，您可能会开始发现模式的出现；在这一点上，读这本书是有意义的。理想情况下，您将具有识别感，并且您将立即欣赏所提议模式的优雅和整洁。您还可能会考虑其中一些模式，这是显而易见的（一旦您了解它们，其中许多就是这样）。您还可以很好地判断特定模式在给定情况下是否适用。

这是另一个警告：仅仅因为您知道所有这些模式并不意味着您必须将它们应用于所有地方。其中一些非常聪明，即使在极其不合适的情况下，人们也会使用它们，最著名的例子是Singleton模式（许多Singleton争议来自不当使用，例如，当一个人没有好处时）。 -instance-only约束）。

设计模式试图解决设计问题。

• 它们被主要用于OOP语言而成为AFAIK。
• 函数编程中不存在某些问题（命令模式是如何制作一流的函数，策略模式是逼近高阶函数的方法……）。这些模式适用于不需要功能的语言（主要是OOP）。
• 它们按字母顺序排序。几种模式是其他模式的组成，或者这些想法是由以前的模式组成的。

在了解了一些功能编程，UML，数据库设计，数据结构和算法之后，我才学习了模式。我实际上只是在备忘单上花了很多时间设计这些模式，并点了点头，说我已经知道了大多数。有些真的很不错，例如单例或“交流”模式（访客，调解人）...

我同意其他几个答案中的观点，即缺乏经验的设计模式可能会很危险。

尽管如此，我还是强烈建议您至少阅读GoF书的第一章。第一部分将向您介绍设计模式，但实际上更多地是关于OO设计的原理，即使经验相对较少，也应该有益于阅读和理解。（我记得一些关键的想法包括“封装变化的概念”，“继承层次结构应该宽泛但不深”。）这件作品主要以其23种模式而闻名-这是对OO设计原理的讨论，这几乎是一种遗憾。告知这些模式也非常有价值。

我的问题是，值得学习GoF书中的模式吗？

绝对！您不仅应该学习软件设计模式，还应该学习一般的设计技术。学习常见问题的通用解决方案是一个奇妙的开始。尤其是一旦您开始研究模式及其权衡。

它们显示出来足以让我学习吗？

最初的《四人帮》一书是通过研究许多软件项目并查看许多开发人员用来解决问题的技术而开发的。作者注意到了一些非常好的技术，以及许多非常不相交的项目中使用的技术，并且致力于将它们抽象化，以至于无论其领域如何都可以使用。

尝试使问题适合经典模式似乎总是违反直觉的

这是一个主要问题。您不会遇到适合解决方案的问题。取而代之的是，“四人帮”设计模式手册中的每个模式都有一个“问题”部分，其他模式目录也有类似的部分，它们描述了何时应应用每个模式。它还描述了使用模式的“后果”-如果您试图避免后果，那么使用模式并不是最好的主意。