我已经阅读了大约4-5本关于设计模式的书籍,但我仍然觉得我在设计模式方面还没有接近中级水平?

我应该如何学习设计模式?

有关于设计模式的好书吗?

我知道这只会来的经验,但必须有一些方法来掌握这些?


当前回答

我领导了一些设计模式讨论小组(我们的网站),并阅读了5或6本模式书籍。我建议从《头部优先设计模式》一书开始,参加或发起一个讨论小组。《Head First》一开始可能看起来有点像Hasboro,但大多数人在读了一两章后就喜欢上了它。

Use the outstanding resource - Joshua Kereivisky's A Learning Guide to Design Patterns for the pattern ordering and to help your discussion group. Out of experience the one change I suggest to the ordering is to put Strategy first. Most of today's developers have experienced some good or bad incarnation of a Factory, so starting with Factory can lead to a lot of conversation and confusion about the pattern.This tends to take focus off how to study and learn patterns which is pretty essential at that first meeting.

其他回答

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

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

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

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

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

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

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

学习测试驱动开发(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.

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

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

练习,练习,再练习。

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

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

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

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

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

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