设计模式之行为

我也不知道为什么很多人写的代码号称是oo，其实是用class 这个关键字来掩饰结构化编程的习惯。我个人觉得这个简直就是侮辱OO这项技术。在设计OO的时候，找出各种domain class或者说business class应该说比较容易，像什么名词法等等都是成型技术了。而OO最难的也是最有意思的就是解决对象间的通讯问题。因为不作设计的结果是对象间不知道怎么通讯，或者说如果要通讯需要暴露一大堆的内部状态。每个控制这类通讯的对象或者类都需要根据不同的情况来处理，写上一堆if else是很正常的事情了。其难维护程度真的是。。。
还有一种是设计过度，最容易导致的结果是一个对象需要和无数个对象通讯，其结果是从这个对象的个体角度看是decouple了，但是从系统的角度看这个对象和那些与之通讯的对象，耦合性很高，尤其是如果是link的通讯，如果那天把中间某个对象修改了，是否可以保持以前的通讯，要重新检查，危险是很高的。

这样基于以上问题，行为模式就发挥作用了，它可以decouple 对象或者类之间的通讯问题，尤其是那些处于不同层次的对象，效果尤其明显，像著名的MVC即observer模式的变种。

1.责任链模式。这个模式比较简单，但是在某些场合比较实用。给人的感觉，整个过程像是做游戏，似乎叫作“传话游戏”。我们举例说明，如果学校进行全校范围的传话游戏。起点是校长，校长知道应该传什么之后，把这些话告诉某个副校长，副校长在告诉另一个副校长，接着。。。。之所以校长要告诉这个副校长，没有什么原因，完全是游戏规则设定的，比如说是名字首字母靠前。完全可以先传话给首字母最大的那个副校长，都无所谓，这个规则是由指定游戏规则的人决定的，校长本身做不了任何决定。在整个传递过程中是看不出层次关系的。当然这种是比较单一的。

                            比较负责的，例如想体现出层次关系的就需要结合组合模式。本层无法解决的问题，抛给上层去做。这点很像java的异常机制。

2。命令模式。说实话，从个体来看，command模式是factory的某个具体应用。不知道是不是个人的理解浅。当同样的一种操作可能在不同的地方被用到的时候，最好定义一个commnad，这样职责改变了，只需要修改一处，避免逻辑的不统一。

3。解析器模式。说实话，没明白具体的特别之处。

4。迭代器模式。这个模式比较亲切，因为在STL中已经使用过了这个。这个模式有个很大的问题就是需要暴露内部状态，所以对于没有friend的语言比较麻烦。这个模式的主要目的是让集合不动的情况，根据需要添加不同的迭代器类，来实现不同的要求。如果为了适应不同的需要而修改集合，会导致整个结构过于复杂。

5。中介者模式。这其实是没办法的时候的一个折衷方案。如果某个动作引起一系列对象的变化，而这些变化之间还是有关联的，则用对象自己控制比较负责，而且万一某些关联需要修改，则整个系统非常难维护。这时候就提供一个专职类来处理这一系列更新。问题在于很可能需要暴露相关的内部状态，而且这个中介者本身可能因为责任重大而变得庞大。

6。备忘录模式。如果做了Do之后，需要做一次UnDo操作，那么Do前的某些状态就需要保留，给UnDo 取出后作恢复动作。

7。