练习，练习，再练习。

你可能读了很多年的关于演奏大提琴的书，但仍然不会用弓演奏乐器，也不会演奏出任何听起来像音乐的东西。

设计模式被认为是一个高级问题;只有当你有必要的经验来认识到它们是有用的，它才与你相关。你能认识到它们的有用是件好事，但除非你亲眼目睹过它们的应用场景，否则几乎不可能理解它们的真正价值。

当你在别人的代码中识别出设计模式，或者在设计阶段识别出一个与模式很适合的问题时，它们就会变得有用;然后检查形式模式，检查问题，确定它们之间的增量是什么，这说明了模式和问题的什么。

这和编码是一样的;K&R可能是C的“圣经”，但从头到尾读几遍并不能给人实际的体验;经验是不可替代的。

The way I learned design patterns is by writing lots of really terrible software. When I was about 12, I have no idea what was good or bad. I just wrote piles of spaghetti code. Over the next 10 years or so, I learned from my mistakes. I discovered what worked and what didn't. I independently invented most of the common design patterns, so when I first heard what design patterns were, I was very excited to learn about them, then very disappointed that it was just a collection of names for things that I already knew intuitively. (that joke about teaching yourself C++ in 10 years isn't actually a joke)

这个故事的寓意是:编写大量的代码。就像别人说的，练习，练习，再练习。我认为，在您了解当前的设计为什么不好并寻找更好的方法之前，您不会很好地了解在哪里应用各种设计模式。设计模式书应该为您提供完善的解决方案和与其他开发人员讨论的通用术语，而不是对您不理解的问题的粘贴解决方案。

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

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

对于这样一个老问题，我只有两分钱

有些人已经提到，实践和重构。我认为学习模式的正确顺序是:

学习测试驱动开发(TDD) 学习重构 学习模式

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

对我来说，提高软件技能的关键是学习TDD。这可能是一个痛苦而缓慢的编码过程，但首先编写测试肯定会让您对代码进行很多思考。如果一个类需要太多样板文件或者很容易崩溃，你很快就会注意到不好的味道

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

Now comes the point where you must read books about patterns, and to my opinion, it is a complete waste of time trying too hard. I only understood patterns really well after noticing I did something similar, or I could apply that to existing code. Without the safety tests, or habits of refactoring, I would have waited until a new project. The problem of using patterns in a fresh project is that you do not see how they impact or change a working code. I only understood a software pattern once I refactored my code into one of them, never when I introduced one fresh in my code.

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

至于我个人最喜欢的，我喜欢O'Reilly出版的Head First Design Patterns。它是用对话的口吻写的，很吸引我。当我阅读它时，我同时检查了我的源代码，看看它是否适用于我所阅读的内容。如果有，我就重构。我就是这样学会责任链的。

练习-练习-练习。

练习，练习，再练习。

你可能读了很多年的关于演奏大提琴的书，但仍然不会用弓演奏乐器，也不会演奏出任何听起来像音乐的东西。

设计模式被认为是一个高级问题;只有当你有必要的经验来认识到它们是有用的，它才与你相关。你能认识到它们的有用是件好事，但除非你亲眼目睹过它们的应用场景，否则几乎不可能理解它们的真正价值。

当你在别人的代码中识别出设计模式，或者在设计阶段识别出一个与模式很适合的问题时，它们就会变得有用;然后检查形式模式，检查问题，确定它们之间的增量是什么，这说明了模式和问题的什么。

这和编码是一样的;K&R可能是C的“圣经”，但从头到尾读几遍并不能给人实际的体验;经验是不可替代的。