the Joy of Pattern 读书笔记

著名建筑大师Alexander对模式的定义是：模式，简单而言，是出现在世界上的一个事物以及对应的规则，这种规则告诉我们如何去建立该事物，什么时候应该建立该事物。它是一个过程，也是一件事物，是对一个事物的描述以及对一个产生该事物的过程的描述。就是说，模式是一种规则之余，它还是一种现象、现状和事物。

第二章 an Introduction to Patterns
一开始通过一个例子引入Observer Pattern，在这本书中，对模式的描述是用以下格式来进行的：

Observer
 Intent 意图
      在对象间定义一个一对多的依赖（dependency）关系，把这些物体分为两种角色，一种是被观察者（一），一种是观察者（多），当被观察者状态发生改变的时候，所有依赖于它的观察者都将得到通知

Varies 变化
      变化的地方在于，观察者的数目是随时可以更新的，并且要保证观察者们总能得到更新（stay up-to-date）

Structure 结构

Comments 评论
      观察者模式也被称为“发布者－订阅者”模式，它的一个主要用途是在document-view结构中（注：在MVC中，主要的两个模式分别是观察者模式和Mediator模式），文章认为，观察者模式的复杂性在于，在实现上选择Push模型还是Pull模型是一个比较难以抉择的问题。（注：Push和Pull并不是针对通知而言，两种模型中都是被观察者通知观察者，而非Pull中观察者去轮询被观察者，两者的区别是，Push模型是指由被观察者向观察者发送状态更改通知的同时发送观察者相应通知所需的一切被观察者内部的信息，而Pull模型则是被观察者只简单地告诉观察者状态发生了改变，观察者需要再次向被观察者查询才可以做下一步的响应动作，两者所使用的场合是不一样的，具体而言，Push模型用在它确定观察者一定会作出响应，因此被观察者只需一次到位发送全部消息，而Pull模型则考虑到观察者众多，未必每一个都需要相同的信息，另外也不是每一个都需要对通知作出响应）

在第三章，介绍了OO相关技术包括UML，其中提到了一个概念：在一个继承体系中，良好的做法是越往上放越多的Code，而Data则放到越下层（子类or实现类）越好。文章是这样解释的：将公共代码尽可能地放到继承层次的上方这样它可以被重用（和数据不同，在继承的过程中，当子类实例不需要使用的时候，代码也不会有额外的cost），而数据元素则应该放到越低越好，这样你不会为不需使用的数据成员付出代价。如下图：


第四章讲的是一个电脑公司的销售系统，对配件的零售和各种搭配销售，要求系统能够统一对待，这里引入了Composite模式，这里不详述，因为还是比较简单的。

第五章讲的是Decorator模式，首先引入了一个汉堡店的系统，介绍了组合爆炸的设计，并引入Decorator，解决了这种问题。

第六章讲的是不同编程语言对模式的实现问题，设计模式和习惯用法（idiom）比较起来，后者是与特定语言相关的，而设计模式则是与语言无关的，这指的是支持OO的语言都支持设计模式，只不过实现起来的复杂程度各有不同，文章举了一个例子用VB来实现State模式，再用Java来实现，得出上述结论。

第七章第八章我就没详细看了，一是觉得这里的图用的不是标准UML图，看起来不太顺眼，另一个则是内容似乎没什么特别的。书的最后三分之一都是附录：代码。

总的而言，这本书不算一本经典的书，由于在图书馆借的，在还书之前翻了一下。下次打算看的模式书是《Head First Design Pattern》。不过得答辩之后才有时间了。