这本书磕磕碰碰，一路啃下，还是颇有成就感的——第一次读完英文影印版的技术书籍，至少从表面上看这本书还是挺厚的大部头
。去年在上个东家实习时起意学习设计模式，之所以选这本书，没有选四人帮那本《设计模式》，源于一同事的推荐。确实这是本好书，在此谢谢这位同事！不过读完这本书也生感慨——以后还是少看英文的，太累了，如果有翻译得不错的译本，还是译本吧——看英文版最明显的好处只是能在星巴克装文艺。
当初看这本书的序时，发现作者之一喜欢下围棋，还写过围棋对弈程序，大感亲切，发了封邮件给他欲交流计算机围棋，当然没有收到回件。磕磕碰碰看得不算轻松（六级没过），好在有朋友的鼓励——一位大牛对我说，设计模式是程序员进阶的必由之路，好好学。深然其说。
历来有对设计模式的批评，举其两例：
1）“设计模式让软件开发生搬硬套现成的模式。”
驳：软件需求千变万化，故软件设计的最高境界应当是无招胜有招——视需求变化，或用23种模式，或自创模式，举重若轻，不拘一格。但除非天纵奇才，无师自通，我等凡夫俗子还是需要学习已有的模式来“悟道”，以求更上一层楼。
2）“设计模式反映编程语言的缺陷。”
驳：对于C++这样的对软件工程支持不佳（我认为确实如此）的古代编程语言，确实需要些设计模式来实现复杂的设计。而对于一些“先进”的语言，很多设计模式显得多余，因为语言本身就包含了，或框架本身就实现了。以我相对熟悉的Objc为例，proxy pattern有着语言层面的支持，不需要那套复杂的结构；observer pattern有着框架层面的实现（Cocoa中的Notification)，也不需要自己写。但设计模式依然值得学习，乃至必须学习——若一直停留在应用层面而不去深究个中道理，那将永远停留在菜鸟阶段。例如我见过一牛人随手用C++写个引用计数的模板（boost库中的shared_ptr也支持引用计数），令我大为佩服——shared_ptr并不妨碍自己写一个引用计数模板。知其然亦知其所以然，应用时方能如鱼得水，驾轻就熟。
非常喜欢这本书每章的“套路”，1）给出软件需求，求设计。2）在不断的探讨中引入模式，并介绍该模式。3）为什么要这样设计，道理何在？然后引入一个面向对象原则。大致如此。这样的套路也正好说明，原则是道，模式为术。
设计需要溯本求源的思考，绝非23个模式所能囊括。针对本质设计，而非针对功能设计——这是本人极为认同的一句话。以移动开发为例，项目需求千变万化，还“朝三暮四”，唯有看清本质，才能对症下药。
“为学日益，为道日损。”