花了两个月时间，终于完整的看了一遍这本书。我的感觉，会不会设计模式，不是看你是否知道这些设计模式的名字，知道他们的用途；而是看你在设计的时候，是否会根据问题选择合适的模式。而这里“合适”二字又包含了很多的内容，什么是合适，什么是不合适。这个本书告诉我们，能够容纳变化，不因为需求变化而违背OO设计原则的设计是合适的。
那么什么是OO设计原则呢？封装，继承，多态是基本的OO设计工具，基于这几个工具建立了如下的原则：
1. Open-close原则，对修改close，对扩展open；
2. SRP，单一职责原则，所有的类只做一件事情，如果某个类做了两件事情，考虑一下是否应该拆分；
3. DRY，不重复原则，浅层次的代码不要重复，高层次的需求分析，逻辑模块不要重复；
4. LISKOV可替换原则，所有子类出现的地方，必须可以替换成基类，否者这个继承关系是存在问题，别人读起来不容易理解；
5. 如果你发现子类需要做一些父类做不了的事情，可以用delegate，composition，aggregation来替换继承。
这些基本原则还可以进一步扩展成 不和陌生人讲话，面向接口而不是对象等。
怎样才能让我们的设计符合这些原则呢？答案就是设计模式。回到这本书，它按照以下步骤讲述设计模式：
1.一个需求；
2.一个简单的设计；
3.需求变化；
4.对简单设计进行修改；
5.分析新的设计有什么问题，违背了哪些设计原则；
6.引入设计模式；
7.分析该模式与其他模式的关系。
这个叙述的方式揭示了一个道理，我们并不是为了模式而模式，而是为了解决问题而需要设计模式。用模式并不是为了点缀我们的代码，仿佛不用模式显示不出来我们的代码水平。用模式是因为为了解决这个问题，必须要这么做，不这么做，就违背了OO设计原则。就会导致维护和理解上的困难。导致项目成本的增加，导致系统质量的降低。
相对而言，GOF的书更像是一个列表，列举了所有的模式，描述了模式是什么，却没有告诉你为什么要这么做。因此，它适合于当你想用一个模式时，帮助你了解模式的细节。
而现实中，往往是先有问题驱动，再有设计模式。当你分析问题，综合考虑各方面的冲击力，最终选择一个模式。或者说这些力量的合力，把你推向一个模式。
最后，这本书还教育我们，设计模式可以组合起来解决问题。一方面我们可以从模式的使用中总结经验，另一方面我们可以根据问题找到新的模式。
确实是一本好书。