我读过4-5本关于设计模式的书，但我仍然觉得我在设计模式方面没有接近中级水平？

我应该如何去学习设计模式？

有没有关于设计模式的好书？

我知道这只会有经验，但一定有办法掌握这些？

我读了三本书，直到我读了奥雷利的头一设计模式，我还是不太了解模式。这本书使我大开眼界，解释得很好。

最好的方法是从它们开始编码。设计模式是一个伟大的概念，仅仅从阅读它们就很难应用。采取一些您在网上找到的示例实现，并围绕它们进行构建。

一个很好的资源是数据和对象工厂页面。他们会仔细研究这些模式，并给出概念和现实世界的例子。他们的参考资料也很好。

这个老问题我两分钱

一些人已经提到，练习和重构。我相信学习模式的正确顺序是：

大多数人忽略了1，许多人相信他们可以做2，几乎每个人都会直奔3。

对我来说，提高软件技能的关键是学习TDD。这可能需要很长时间的痛苦和缓慢的编码，但是首先编写测试肯定会让您对代码有很多想法。如果一个类需要太多的样板或者很容易被打破，你会很快注意到臭味。

TDD的主要好处是，您不再害怕重构代码，并强迫您编写高度独立和内聚性的类。如果没有一套好的测试，触摸没有损坏的东西就太痛苦了。有了安全网，您将真正冒险地对代码进行巨大的更改。那是你真正开始从实践中学习的时刻。

现在到了你必须阅读有关模式的书籍的时候了，我认为，这完全是浪费时间，太费劲了。我只在注意到我做了类似的事情之后才真正理解模式，或者我可以将其应用到现有的代码中。如果没有安全测试或者重构的习惯，我会等到一个新的项目。在新项目中使用模式的问题是，您看不到它们如何影响或更改工作代码。只有当我将代码重构为其中一个时，我才理解软件模式，而不是在代码中引入新的模式。

Derek Banas为设计我非常喜欢的模式制作了YouTube教程：

http://www.youtube.com/playlist？列表=plf206e906175c7e07

他们的时间可能有点短，但他的时间安排和演讲让他们非常乐于学习。

练习，练习，练习。

你可以读到多年来演奏大提琴的故事，但仍然不能对乐器鞠躬，做出任何听起来像音乐的东西。

设计模式最好被认为是一个高层次的问题；只有当你有必要的经验来认识到它们是有用的，设计模式才是相关的。很好，你认识到它们是有用的，但是除非你看到过它们会应用或已经应用的情况，否则几乎不可能理解它们的真正价值。

当你在别人的代码中识别出设计模式，或者在设计阶段识别出一个与模式很匹配的问题，然后检查正式模式，检查问题，并确定它们之间的增量是什么，以及它对模式和问题的描述是什么时，它们就变得有用了。

它实际上与编码相同；K&R可能是C语言的"圣经"，但阅读它几遍并不能提供一种实践经验；经验是无法替代的。

实践练习。我认为4到5本书甚至是过度的阅读练习，没有一定的练习量。我认为，实现这一点的最佳方法是开始使用模式重构您当前的项目。或者，如果您没有任何正在积极工作的项目，那么只需按照自己的方式进行，然后尝试重构到模式。

如果你没有经历过他们所解决的问题，你就不能完全感激他们。请记住，它们不是银弹——你不需要记住它们，并且在飞行中很难应用。我的两分钱…

问问自己这些问题：

他们做什么？

它们是如何解耦/耦合的？

你什么时候应该使用它们？

你什么时候不应该使用它们？

什么语言功能缺失会让他们消失？

使用它会产生什么技术债务？

有没有更简单的方法来完成这项工作？

已经给出了许多很好的例子。我想增加一个：

误用它们。你不需要故意这样做，当你试图将它们应用到你最初的设计模式中时，就会发生这种情况。在此期间，您将看到的每个问题似乎都完全符合一种设计模式。通常，由于某种原因，这些问题似乎都适合相同的设计模式(Singelton是其中的主要候选者)。

你将应用这个模式，它将是好的。几个月后，您将需要更改代码中的某些内容，并发现使用该特定模式并不是那么明智，因为您将自己编码到一个角落，并且需要重新重构。

当然，这并不是一个真正的"做那件事"，你21天内就能学会答案，但根据我的经验，它最有可能让你对这件事有一个很好的了解。

我发现，要理解或理解某些模式的好处有点困难，直到一个人理解它们解决的问题，以及其他(更糟的)实现问题的方法。

除了gof和posa的书，我没有真正读过，所以我不能给你其他的建议。实际上，您只需要了解问题域，我认为许多经验不足的开发人员可能无法理解模式的好处。这对他们来说并不轻微。当一个人必须首先与糟糕的选择作斗争时，接受、理解和欣赏好的解决方案要容易得多。

祝你好运

对于书籍，我会推荐解释的设计模式，并首先介绍设计模式。要真正了解这些模式，您应该查看现有的代码。寻找你已经在使用的模式。看看代码的气味以及什么模式可以解决它们。

你试过《四人帮》吗？

设计模式：可重用面向对象软件的元素

你读过艾伦·萨洛威的《设计模式解释》吗？

这本书与其他设计模式书有很大的不同，因为它不是模式的目录，而是主要介绍一种分解问题空间的方法，该问题空间很容易映射到模式。

问题可以分为两部分：共同的和不同的。一旦完成了这项工作，我们就将常见的事情映射到一个接口上，并将不同的事情映射到一个实现上。本质上，许多模式都属于这个"模式"。

例如，在策略模式中，常见的事物表示为策略的上下文，可变的部分表示为具体的策略。

我发现这本书与其他模式书相比，具有很强的启发性，对我来说，这些模式书与阅读电话簿同样令人兴奋。

我领导了几个设计模式讨论小组(我们的网站)，阅读了5到6本模式书籍。我建议从"头部优先设计模式"一书开始，参加或开始一个讨论小组。头一本书一开始可能看起来有点哈斯博罗，但大多数人在读了一两章后都喜欢它。

使用优秀的资源——Joshua Kereivisky的学习指南，为模式排序设计模式，并帮助您的讨论小组。根据经验，我建议订购的一个变化是将战略放在首位。今天的大多数开发人员都经历过工厂的一些好的或坏的化身，因此从工厂开始可能会导致很多关于模式的对话和混淆。这往往会使人们不再关注如何学习和学习模式，这在第一次会议上是非常重要的。

我推荐HeadFirst设计模式。阅读这本书是不够的，在吸收了概念之后，你需要找到很多问题的答案，并试图找到现实生活中的应用程序，在这些模式中可以使用。我也这样做了，开始问问题，即使那些问题看起来很愚蠢。

我学习设计模式的方法是编写大量非常糟糕的软件。当我12岁的时候，我不知道什么是好是坏。我刚刚写了一堆意大利面代码。在接下来的10年左右，我从错误中吸取教训。我发现了什么起作用了，什么不起作用了。我独立发明了大多数常见的设计模式，所以当我第一次听到什么是设计模式时，我很兴奋地了解到它们，然后很失望它只是我凭直觉所知事物的名称集合。(关于在10年内自学C++的笑话其实不是一个笑话)

故事的寓意：写很多代码。正如其他人所说，练习，练习，练习。我认为，除非你理解为什么你当前的设计不好，并寻找更好的方法，否则你将不知道在哪里应用各种设计模式。设计模式书应该为您提供一个完善的解决方案和一个与其他开发人员讨论它的常用术语，而不是一个针对您不理解的问题的粘贴式解决方案。

阅读设计模式、实践编码的概念并不能真正帮助IMO。当你阅读这些书时1。寻找一个特定的设计模式解决的基本问题，从创造模式开始是你最好的选择。2。我敢肯定您以前编写过代码，分析您是否面临设计模式旨在提供解决方案的相同问题。三。尝试重新设计/重新考虑代码，或者重新开始。

关于资源，您可以检查这些

1是快速入门，2是深入学习。3将解释或应该让你认为你在2中学到的东西适合企业软件。

我的2美分…

我不知道最好的书，但是纯粹主义者可能会说设计模式：可重用面向对象软件的元素

至于我个人最喜欢的，我喜欢奥雷利出版的"头先设计"模式。它是以对话的声音写的，对我很有吸引力。当我阅读它时，我同时检查了我的源代码，看看它是否适用于我正在阅读的内容。如果有，我就重构。这就是我学习责任链的方式。

实践-实践-实践。

我的建议是实现其中的一些并分析它们的一些实现。例如，在.NET中，如果您查看数据适配器，就可以使用适配器模式；如果您稍微深入了解一下框架，就可以使用其他适配器模式。

设计模式只是工具——有点像库函数。如果你知道它们在那里，以及它们的近似函数，你可以在需要的时候把它们从书中挖出来。

设计模式没有什么神奇之处，任何一个优秀的程序员在任何书出版之前都会自己计算出90%的设计模式。在大多数情况下，我认为这些书在简单地为各种模式定义名称方面最有用，这样我们可以更容易地讨论它们。

我认为研究设计模式也很困难。您必须了解更多关于OOP的知识和一些中大型应用程序开发的经验。对我来说，我作为一个小组的开发人员学习进行讨论。我们遵循一个学习指南来设计他们已经完成模式研究的模式。有C和JavaScript开发人员联合在一起。对我来说，很有趣的是C开发人员用JavaScript编写代码，而JavaScript开发人员也用C代码编写代码。在我离开一个会议之后，我也在家里研究和阅读了几本书来复习。在我的脑海中，更好的理解和记住的方法是在这里用C和javascript中的例子来写博客http://tech.wowkhmer.com/category/design-patterns.aspx。

我建议在进入每个设计模式之前，请先了解模式的名称。另外，如果有人知道这个概念，请解释并给出一个例子，不仅是编程，而且是在阅读世界中。

例如：

工厂方法：

阅读世界：我只给5美元，10美元或20美元，它将生产比萨饼回来，而不知道它如何生产，我只得到一个小，中或大比萨饼取决于钱的投入，以便我可以吃或做任何事。

编程：客户机只是将参数值$5、$10或$20传递给工厂方法，它将返回pizza对象。因此，客户机可以在不知道如何处理的情况下使用该对象。

我不确定这对你有什么帮助。这取决于参加会议的人的知识水平。

我认为您需要检查作为开发人员遇到的一些问题，在第10次因为另一个设计变更而不得不修改代码之后，您就拔出了头发。您可能有一个项目列表，其中您觉得有很多返工和痛苦。

从这个列表中，您可以派生出设计模式要解决的方案。是否有一段时间需要对不同的数据集执行相同的一系列操作？您是否需要能够为应用程序提供未来的功能，但希望避免为现有类重写所有逻辑？从这些场景开始，返回到模式目录以及它们应该解决的各自问题。您可能会看到GOF和项目库之间的一些匹配。

对于初学者来说，head-first设计模式可以做到，一旦我们熟悉了所有的模式，然后尝试将实时对象可视化为这些模式。

这本书将帮助你理解基本概念，除非你在现实世界中实现之前，你不能精通设计模式。