我已经阅读了大约4-5本关于设计模式的书籍,但我仍然觉得我在设计模式方面还没有接近中级水平?
我应该如何学习设计模式?
有关于设计模式的好书吗?
我知道这只会来的经验,但必须有一些方法来掌握这些?
我已经阅读了大约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.
其他回答
Derek Banas在youtube上制作了我非常喜欢的图案设计教程:
http://www.youtube.com/playlist?list=PLF206E906175C7E07
他们可能在时间上有点短,但他的时机和呈现方式使他们非常愉快地学习。
练习练习再练习。我认为4到5本书在没有大量练习的情况下是一种过度的阅读练习。我认为,做到这一点的最佳方法是开始使用这些模式重构您当前的项目。或者,如果你没有任何正在积极进行的项目,那么就按照你自己的方式来做,然后尝试重构模式。
如果你没有亲身经历过他们所解决的问题,你就无法充分欣赏他们。请记住,它们不是银弹——你不需要记住它们,并在飞行中努力应用它们。我的意见…
对于这样一个老问题,我只有两分钱
有些人已经提到,实践和重构。我认为学习模式的正确顺序是:
学习测试驱动开发(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.
问自己这些问题:
他们做什么?
它们是如何耦合的?
什么时候使用它们?
什么时候不应该使用它们?
什么缺失的语言特征会让它们消失?
使用它会导致什么技术债务?
有没有更简单的方法来完成工作?
设计模式只是工具——有点像库函数。如果你知道它们和它们的近似函数,你可以在需要的时候从书中找到它们。
设计模式并没有什么神奇之处,任何优秀的程序员都能在任何书籍问世之前自己找出90%的设计模式。在大多数情况下,我认为这些书在简单地为各种模式定义名称方面最有用,这样我们就可以更容易地讨论它们。