模式设计学习（1）

    开始学习一下模式设计（Design Pattern）,这里的模式应该只是狭义的面向对象中类之间的一些定式，而非传统广义上的“模式”。其实之所以创建出模式来，无非是对类之间常用关系的一些总结。GOF总结了经典的二十几个，其实应还有很多，无论我们是否学习过模式设计，在我们软件设计中都有可能去无意中“匹配”到某种模式，因为我们总有设计出类之间的关系。

    类之间的关系无非就是那几种：组合，聚合，继承，关联等。

    今天先学习下两种“行为模式”：Template模式和Strategy模式。这两种在我看来都是解决分层问题的。都是教我们如何调用。不同之处是前者使用了继承来分层，后者使用了聚合来分层。两种模式如下图：

   

 

    对Template模式可以这样理解，完成某项任务有一套固定的做法（接口），但每个做法如何操作还不固定（需要具体实现），这样我们定义一个抽象类，其中包含了这些抽象做法。这些抽象做法或者有默认行为（你可以不去修改），或者一定要你去覆盖（override）。

    对Strategy模式可以这样理解，上层完成某项工作对外暴露某些接口，但是，该层自己并不真正去操作，而是委托下层去具体实现，这样上层的封装类和具体实现的类（对象）构成了上下层的关系。

    Template模式最典型的例子就是App Framework。Template模式获得一种反向控制结构效果，这也是面向对象系统的分析和设计中一个原则DIP（依赖倒置：Dependency Inversion Principles）。其含义就是父类调用子类的操作（高层模块调用低层模块的操作），低层模块实现高层模块声明的接口。这样控制权在父类（高层模块），低层模块反而要依赖高层模块。

   Strategy模式则是很多场合都会用到，比如一个xml解析器（XmlParser），对外接口可能是输入字符串，返回dom tree。但是内部的解析算法则由具体算法类（XmlParserStrategy）来完成。这样，XmlParser对外隐藏了算法实现，将具体实现交给了下层去完成。

   上面两种模式都是一种对象和对象之间的“直接调用”，而对象间可能存在“回调”，这就要我们再来看另外一种行为模式，Observer模式。这种模式应该是面向对象里用的最多的一种了，该模式里有两个基类Subject和Observer，这两个类可能分别派生出一些具体的类（对象）。2者存在分层的概念。哪个是上层哪个是下层呢？Observer派生出的类对象（可能是多个具体对象）是观察者，它（们）是上层，而Subject的具体对象是下层。这里Observer类是个虚基类，它表示一个接口。上层的具体类要实现这个接口，才能获得下层subject抛上来的消息。为什么这个模式很重要呢，因为当前的应用程序很多都是消息（事件）驱动型的，而这种模式恰恰模拟了抛消息的模式。

  

  总之上层对下层的“调用”与下层对上层的“回调”都很重要，而为了减少层间的依赖（松耦合），我们分别使用了不同的模式去实现之。

 

  题外话：最近在看QT，我之前写了一篇笔记来阐述我对signal和slot的看法。我觉得signal/slot恰恰就是用最简单的方法实现了Observer模式，包含signal的类对象相当于Observer派生的具体对象，而相应的slot的类对象就是上层的Subject。把signal和slot连接起来后，就相当于下层向上层抛消息（事件）。所以两个对象A和B，如果A作为signal向B的slot发消息，那么就默认了A和B的层级关系（B高层，A低层），我们最好就不要再用B的signal想A的slot发消息，这样就成了双向依赖，这种双向依赖正式我们千方百计要避免的设计误区。

  最后我们再来看看State模式，这种模式和Strategy模式很类似。

 

    State模式和Strategy模式有很大程度上的相似：它们都有一个Context类，都是通过委托（组合）给一个具有多个派生类的多态基类实现Context的算法逻辑。两者最大的差别就是State模式中派生类持有指向Context对象的引用，并通过这个引用调用Context中的方法，但在Strategy模式中就没有这种情况。因此可以说一个State实例同样是Strategy模式的一个实例，反之却不成立。实际上State模式和Strategy模式的区别还在于它们所关注的点不尽相同：State模式主要是要适应对象对于状态改变时的不同处理策略的实现，而Strategy则主要是具体算法和实现接口的解耦（coupling），Strategy模式中并没有状态的概念（虽然很多时候有可以被看作是状态的概念），并且更加不关心状态的改变了。