《Design Patterns》是一本由Erich Gamma / Richard Helm / Ral著作，Addison-Wesley Professional出版的Hardcover图书，本书定价：$54.99，页数：416，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《Design Patterns》读后感(一)：很棒的书——学术界和工业界相互促进
刚看完。
这本书貌似也有些争议，但是争议不是太大，主要是泛函编程的支持者，特别是lisp的程序员，意思是大概是很多东西在lisp这些语言里面都很容易实现，没必要搞这么麻烦。不过OO当年成为编程的主流是有原因的。有些软件，例如登火星之类的，就目前看，不是10个lisper就能完成的，还是需要IBM的“人浪”战术。
我感觉这本书棒在当年那个工业界感到迷茫的时候，学术界出来了相应的研究。就今天看，design pattern对工业界的贡献非常大。
对于程序员来说，熟悉熟悉design pattern，起码看别人代码的时候容易很多，而且自己写代码的时候也会注意到结构设计。
记得本科的时候看了个开头，就看不下去了，体会不到内在的意义。最近经受了数百篇论文的压榨，后头来看这些东西觉得很有意思，也没觉得什么地方难以理解。
总之，好书！
《Design Patterns》读后感(二)：GoF —— 一本被误解很深的书
误解1：设计模式只有23种
GoF在前言中就说到“We don’t consider this collection of design patterns complete and static; it’s more a recording of our current thoughts on design.”这本设计模式领域的开山鼻祖，第一扩展了人们的面向对象设计思路，第二则启示人们用模式来总结面向对象设计经验。可惜当前很多设计模式的书籍，逃不出这本书的藩篱，一来讲不出什么新意，二来也不利于读者眼界的开阔。对于已有的设计模式的归纳，可见[1]和[2]。
误解2：书中的每个设计模式已是定式
在书中的每个模式的实现部分，GoF都特别强调variation，什么时候可以省去某个结构，什么时候可以利用语言特性……正如前言中所说，设计模式不是静态的，可以根据需要变化，甚至可以说，在特定的环境下（比如语言），依葫芦画瓢就是误用。而且，不同模式的组合往往才能达到最大的灵活性（见图1.1 Design pattern relationship），而何时该组合、如何组合，则考验设计者功力了。
误解3：设计应该以模式为导向
HFDP(Head First Design Pattern)的作者说，使用设计模式有3个层次：
•Beginner——初级的时候无处不用设计模式，认为用的模式越多，设计就越好
•Intermediate——中级的时候知道何时该用什么设计模式，什么时候不该用
•Zen——到了禅的境界，设计模式被用来简化设计，让设计更优雅
把设计模式“塞到”设计中，那就只处于初学者的层次。23种设计模式只是描述了在一个上下文（即书中的Applicability）下的最佳实践，脱离了对应的上下文，往往会造成画虎不成反类犬的效果（Anti-Pattern）。Erich Gamma在接受采访时也承认过去在书中宣扬的方法不当，鼓励refactor to patterns[3]。
误解4：GoF是学习设计模式的必读书
GoF确实是经典，这本书已经出版了15年了，15年在软件工程的历史里可是很长的一段时间。在这15年里，软件工程也发生了很多变化，新的语言、方法、实践层出不穷，smalltalk不再流行，C++也收到很大冲击，现在的OO世界，Java和C#是主流语言。模式虽是独立于实现的，但鉴于每个语言都有不同的特性，对模式的实现有或大或小的差异，对于浸淫在某一门语言中的人，去看针对特定语言的设计模式书收效更大。而另一方面，设计模式的本身也在变化，有些经典的模式不再常用，HFDP的作者直接将GoF中一些不常用的模式扔到了附录中。GoF放在当今，宜作为设计模式的起点读物（读一本是不够的）和参考读物。
总之，创造力是设计师自己的，GoF只是给你一个指引。
《Design Patterns》读后感(三)：真不知道看了多少遍我才有勇气跟自己说我算是读过了
真不知道看了多少遍我有勇气跟自己说我算是读过了. 期间也读了些其他讨论OOD的书, 这本算是最"干"的.
更多时候那些模式不是自己刻意去使用的, 要嘛是从别人代码里"读出来的", 要嘛就是自己通过朴素的方法(分析->最直接的实现->重构)"渐渐浮现出来的", 自己刻意去套用的情况只出现在一开始乐此不疲地尝试各种模式的时候.
对我而言, 获益有:
1. 通过识别模式快速了解作者的意图;
2. 方便交流(包括和自己对话), 简化了对"问题-设计-利弊"的描述, 为什么name是pattern的四要素, 一个name包含了太多的信息.
3. SOLID原则记心间, 刻意地去忘掉具体的模式, 让设计原则在背后悄悄的影响着自己在设计实现中的一个个小决定.
《Design Patterns》读后感(四)：毁了一代工程师
在支持函数式的动态语言里， 绝大多数design pattern都变的简单直接，以至于你甚至感觉不到它们的存在。
在面向对象的限制之下，敞开的大门不走，偏要爬窗户。
比如strategy pattern的本意是通过composition而非inheritance，使能够在运行时（runtime）动态绑定某对象的成员方法。
就像游戏里某个actor能够在各种attack() 方法之间自由的切换，如使用手枪，手雷，狙。
在动态语言里直接把attack函数赋值给actor就可以了，根本没有什么pattern可言。
在Java/C++里却必须把attack函数包装成behavior object才能赋值给actor。
command pattern也类似，可以参照以下Erlang的message passing。
Google研院的Peter Norvig大叔总结了23个design pattern在lisp/python等函数式语言之下的对应物。
引用如下
=====================================================
16 of 23 patterns are either invisible or simpler, due to:
First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility
First-class functions (4): Command, Strategy, Template-Method, Visitor
Macros (2): Interpreter, Iterator
Method Combination (2): Mediator, Observer
Multimethods (1): Builder
Modules (1): Facade
=====================================================
总结：
Design Pattern揭露了OOP系统本身的不灵活