以下是我从最后两个部分：气象站案例研究和ETS案例研究中得到的一些收获，以及个人的一些认知及见解：
“OBSERVER模式”又称为回归为模式，其最大的推动力来自开放封闭原则。使用这个模式的动机就是为了在增加新的观察对象时可以无需更改被观察的对象。这样，被观察对象就可以保持封闭。Observer是一个抽象类，具体的DigitalClock依赖于它，Subject的具体方法也依赖于它。因此，依赖倒置原则也运用于其中，Subject 不具有抽象方法，故它与Clock间的依赖关系可能违反了DIP。但是，Subject是一个绝不应该被实例化的类。它只在派生类的上下文中才有意义。故，尽管subject不具有抽象方法，但它是逻辑抽象的。在C++中，我们可以通过使Subject的析构函数是纯虚的或者使它的构造函数是受保护的来强制它的抽象性。
“ABSTRACTServer，Adapter和BRIDGE模式”中揭露了说不存在完美的结构，只存在那些试图去平衡当前的代价和收益的结构。随着时间的过去，这些结构肯定会随着系统的需求的改变而改变的，管理这种变化的诀窍是尽可能的保持系统的简单和灵活。使用ADAPTER模式的解决方案是简单和直接的。它让所有的依赖关系都指向正确的方向，并且实现起来非常简单。BRIDGE模式稍微有些复杂，故开始时作者不建议使用此种模式，直到明显可以看出完全需要完全分离连接策略和通信策略并且需要增加新的连接策略时，才使用这种方法。同样的像往常的模式一样，模式是既能带来好处又需要付出代价的东西，应该按照实际来选择自己所需要的模式。
“PROXY,STAIRWAY TO HEAVEN模式”又称为管理第三方API，这种模式相对比较容易创建，并且对包含业务规则的对象具有最小的影响，但它需要一种实现了对多重继承支持的语言，such as :c++。对于PROXY模式，建议开始时先使用FACADE 模式，然后在必要时使用重构，如此便可以为自己减少很多不必要的麻烦。
代码可以驱动着设计的发展和进程。大部分人认为需求不是那么易变，其实不然，就像天气变化是不可预测的，作为预测人必须会对 情况划定界限，从代理类到实现类的依赖关系并不代表着很大的维护风险，不需要工厂模式。
Visitor模式系列给我们提供了许多无需更改一个层次结构中的类即可修改其行为的方法。此外，它们也提供了用来分离不同种类的功能的机制，从而使类不会和很多其它的功能混合在一起，同样有助于我们保持CCP，此结构中也使用了SRP，LSP以及Dip。此模式是很具有诱惑力的，他们很容易失去自制力，在使用它们时最好保持较高的警惕，一般的需要它来解决问题某一问题时可以使用更简单的方法来解决此问题。
有限状态机并未被充分使用，许多情形中，使用它们有助于创建更清楚，更简单，更灵活以及更准确的代码，使用State模式以及根据状态迁移表生成代码的简单工具，可以给我们提供很大的帮助。
框架中处理计算几何的部分，或者有关答案文件存取的部分等等这些参数文件的存在使得每个绘图题应用程序可以驱动自身的许多不同变体，但是由于时间及空间的限制，并做不到这一点。
从作者的展示中，我还了解到了如何使用例和类型构成个应用领域模型来分析问题的过程，类，对象以及组件是如何被结合到描述软件构架和构造的静态以及动态图中，知晓了这些概念的UML表示法以及如何使用这些表示的方法，最够还了解了这些方法是如何参与到软件设计的思考中的。总之，此书形象生动的向我介绍了敏捷软件开发的相关知识，分析了相关案例，让我身临其境感受了作者的境界，升华了自己的灵魂！