练习，练习，再练习。

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

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

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

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

有很多很好的例子。我想补充一点:

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

你应用这个模式就会很好。几个月后，您将需要更改代码中的某些内容，并发现使用特定的模式并不明智，因为您将自己编码到一个角落，您需要再次重构。

当然，这并不是一个真正的“做了就会在21天内学会”的答案，但以我的经验来看，这是最有可能让你对问题有一个很好的洞察的答案。

练习，练习，再练习。

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

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

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

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

你读过Allan Shalloway写的《设计模式解释》吗?

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

问题可以分解为两部分:共同的和不同的。一旦完成了这一步，我们就可以将常见的内容映射到接口，并将不同的内容映射到实现。从本质上讲，许多模式都属于这种“模式”。

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

我发现这本书与其他模式书相比非常发人深省，对我来说，阅读电话簿的兴奋程度是一样的。

设计模式只是工具——有点像库函数。如果你知道它们和它们的近似函数，你可以在需要的时候从书中找到它们。

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

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

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

练习-练习-练习。