你试过《四人帮》这本书吗?

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

I would think it is also difficult to study design patterns. You have to know more about OOP and some experiences with medium to big application development. For me, I study as a group of developers to make discussion. We follow A Learning Guide To Design Patterns that they have completed the patterns study. There are C# and JavaScript developers join together. It is fancy thing for me is the C# developer write codes in JavaScript and the JavaScript developer do the same thing for C# codes. After I leave a meeting I also research and read a few books at home to review. The better way to understand more and remember in my mind is to do blogging with examples in both C# and JavaScript in here http://tech.wowkhmer.com/category/Design-Patterns.aspx.

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

例如:

工厂方法:

阅读世界:我只要给钱5美元、10美元或20美元，它就会生产出披萨，而不知道它是如何生产的，我只会得到一个小的、中等的或大的披萨，这取决于我投入的钱，这样我就可以吃或做任何事情。

编程:客户端只需将参数值$5，$10或$20传递给factory方法，它将返回Pizza对象。因此客户端可以使用该对象，而不知道它是如何处理的。

我不确定这能帮到你。这取决于与会者的知识水平。

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)

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

问自己这些问题:

他们做什么?

它们是如何耦合的?

什么时候使用它们?

什么时候不应该使用它们?

什么缺失的语言特征会让它们消失?

使用它会导致什么技术债务?

有没有更简单的方法来完成工作?

练习，练习，再练习。

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

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

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

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

我推荐HeadFirst DesignPattern。阅读书本是不够的，在吸收了这些概念之后，你需要为你脑海中出现的许多问题找到答案，并试图找出这些模式在现实生活中的应用。我也在做同样的事情，开始问问题，即使这些问题看起来很傻。