设计模式

这里提到了 IoC 概念，可以看出这些概念在成书时还不成熟。它和 DI 有区别，意义也较模糊，看起来跟多态一样。

Interpreter Pattern（解释器模式）是我读本书到现在最难理解的模式。可能是因为阅读过程中我一直分不清interpret（解释）和parse（解析）的区别。Interpreter Pattern是不管parse的。Interpret就是evaluate，这是求值的过程；Parse则是构建可用于求值的语法树的过程；Parse是interpret的先行步骤。 以书中的Sample Code为例： 1）给定一个布尔表达式（书中的C++示例），我要求它的最终值是真还是假——这是interpret；但是给定一行文本，我要读懂这行文本是一个什么样的布尔表达式——这是parse；只有我读懂了这个布尔表达式，我才能对它求值。 2）给定一个正则表达式（书中的Smalltalk示例），再给定一行文本，我要知道这行文本是否匹配这个正则表达式，或者再给定一个文本文件，我要找出文件中匹配该正则表达式的文本——这是interpret；但是给定一行文本，我要读懂这行文本描述的是怎样一个正则表达式——这是parse；只有我读懂了这个正则表达式，我才能用它去匹配任意文本。 所以parse是“读懂”，interpret是用读懂的东西去求值。可能有的时候，这两者的区别并不是那么清晰。 另外，Interpret Pattern和Composite Pattern的确很相似，它们之间有很紧密的联系。两者的类图甚至是一模一样的，只是类的名字有所不同。这更加印证了我读本书过程中一个越来越强的体会：设计模式的目的十分重要；理解一个设计模式时，不要光看它的类图，仅仅知道模式中有哪些类哪些方法是不够的。

我把这一章读了两遍才感觉理解了原型模式的含义，可能是因为实践中没怎么碰到过这种模式。不过Consequences一节写道的原型模式的其中两点好处还是挺让我糊涂：Specifying new objects by varying values和Specifying new objects by varying structure。要是能就这两点举个代码上的例子就好了。可惜篇幅有限。

之前读第2章A Case Study的时候就已经基本理解了抽象工厂模式的思想。这一章对我而言比较新的内容倒是Smalltalk利用自身的类为一等公民和动态类型的特性，使用原型（Prototype）的思路来实现抽象工厂的方法。 Known Uses这一节提到，ET++使用了抽象工厂模式来实现不同窗口系统（如X Windows和SunView）之间的可移植性。不过在第2章2.6节里，作者却是使用桥接模式（Bridge Pattern）来实现同样目的的，理由是不同窗口系统之间的编程接口往往难以兼容。