GoF设计模式读书笔记

花了大概一天时间，把大名鼎鼎的GoF的设计模式看完了。内容很丰富，被如今封为准则的23种设计模式在这本书里面娓娓道来。

正如该书前沿所述，这本书事实上并不是一本适合从头读到尾的书，而是一本类似于手册，却又需要对本书有一个很好的轮廓结构的书。

谈几点收获吧：

• 设计模式本身并非GoF提出的，而是一直存在于这数十年的软件开发中。
• 虽然很多模式之前没有听过，但是当看到他的意图、目的、解决方案的时候，发现：原来以前碰到的问题应该这样解决。还记得09年时候，自己写了一个BIT的外网登陆软件。其中自己一直解决得不理想的问题就是：如何让注册表、托盘菜单、程序主界面的状态信息时刻一致。当初自己采取的就是典型的硬编码（hard coding）：让主程序控制这个信息的通知与更新。这显然是一个有问题的解决方案，导致的一个很明显的后果就是，随着软件功能的丰富，主程序的任务越来越重，控制逻辑越来越复杂，最终导致自己写对一次控制逻辑以后，再也不敢修改代码……sigh。但是看到了书中给出的Observer模式以后，不禁感慨：原来你藏在这里。
• 学习和理解设计模式的一个前提是设计者相信：一个优秀的设计是可以被度量的。“ 当我直觉上不喜欢某个设计时，更好的设计肯定还隐藏在某个角落里。当然，又是附近会有几个不同的角落，我并不是总能确定哪个角落隐藏着更好的设计。”（设计模式解析）
• 设计模式可以通过阅读来理解，但是设计模式的最终归宿还是在于在实际开发中的应用。在以后开发中，应当有意地适当使用设计模式。但是，设计模式并不是一切。设计来源于已有的优秀软件，它月软件开发是相辅相成的关系。因此，任何希望找到先有鸡还是先有蛋的溯源都是错误的行为。
• GoF的设计模式绝对是经典。但是，读完23个设计模式以后，有一种强烈的感觉：模式与模式之间其实并不是彼此独立的，它们在很多问题情境下是存在交集的，因此在掌握好各个模式之后，应该去思考和理解模式之间的组合和标准模式的修改（变通）。
• 设计模式还揭示了一个普遍存在的问题：开发者们总是过早的深入细节，而却没有仔细思考怎样才能更加优雅的解决这个问题以应对软件开发过程中的各方面的变化。
• 读完这本书，整理笔记后。马上翻开了《设计模式解析》。在这本书里面引入了一些新的关于面向对象的思想，同时对设计模式进行了更加易懂的解读和扩展，并对模式之间的组合进行了探讨。有象棋中“双重炮”布阵之感。大家也不妨这样安排阅读顺序。

转载于:https://www.cnblogs.com/liudanking/archive/2012/06/06/2538374.html