设计模式之进化论(1)

zhqh — Thu, 14 Aug 2008 04:54:00 GMT

这次这个主题还是关于设计模式的，在早期的一篇已经写了，一直到现在还没继续完成他。而为什么又写这主题呢？因为，这跟前面的主题确有不同之处，这回主要阐述了设计模式的进化问题。
到了今天，终于有点时间完成这主题了...
目录结构：
1.基本概念
2.基础结构
3.基于基础结构的模式演化过程
其实这样的层次是很简单了，在基础结构诞生之后，基于委托的模式已经算是很明了的了。然后，大概介绍几个基于委托的模式的演化过程
1.基本概念
这里列出了几个相关概念。
委托
临时委托
DIP原则
客户
中介者（我叫它为管理器和调度器，当然，在不同模式中，取名有所差别）
目标对象
2.基本结构
编程中，当你需要某种服务，你当然会去调用具有该服务的目标对象（有可能是更高层次的组件），很显然，结果，就是这样一个的结构。client调用ClassA来实现某种服务。

比如，为了处理字符串，你会new String，然后进行一些处理。甚至，你的代码里到处都充砌着String的足迹，这样确实能很好的解决问题。这样的结构背后的理由呢？首先，我想说的是，这样的结构违反了DIP原则，细节应该依赖于抽象，而不是依赖于另一个细节。这样的依赖关系会使代码缺乏弹性，很难复用，迁一发动全身。应该改进的是，把ClassA的抽象提取出来，然后让client去依赖于IClassA,变成如下图：

但是，事实上，我们没有这么做。这是因为String这样的类实例具有很强的稳定性，这样的稳定性保证了它不会经常变化，这就是行为的稳定性因素。这样具有强稳定性的类没必要复杂化。所以，我们让接受了client依赖于细节的结果。这样的细节是单一的。
然而，需求是变化的，解决方案是不稳定的，在我们的项目中，会有大量不具稳定性的因素存在。在项目中，你会发现存在着多个同性质而实现细节有异的行为类存在。
比如存在着这样的三个类ClassA,ClassB, ClassC,
client在不同地方调用它。结构图如下：

我假设client是个main函数，OK，调用的代码应该是这样，
void main(){
        ...
       ClassA a = new ClassA();

(1)    a.MethodOne();
(2)    for(int i=0;i<3;i++){
(3)       a.MethodTwo();
(4)    }
       .....

       ClassB b = new ClassB();
(5)    b.MethodOne();
(6)    for(int i=0;i<3;i++){
(7)       b.MethodTwo();
(8)    }

}
这样的代码，给你的感觉怎么样，也许还蛮过得去，他确实是跑得起来。但这样的代码存在潜在的危险性。应该被归入糟糕设计的范畴里。首先，客户面对不具稳定性的因素，根据DIP原则，它没有提取抽象，违反了DIP原则。其次，client（main）必须负责策略的组织(我把类似(1)(2)(3)(4)的目标对象的这样一组调用过程称为策略组织),也就是说，client面对的不是一个完全的黑盒子，他面对的是一些半黑的盒子，同时，他必须知道怎么把这些半黑的盒子组装起来。例如(5)(6)(7)(8)这些对客户来说，是一组半黑的盒子。客户本身的任务太重了，同时，这样的任务弥漫在客户的头和脚之间，及其零乱。很快，又有类似的另一种不具稳定性的因素参与这样的弥漫活动，最终的客户将被淹没在不稳定性因素组成的大海里。如果，刚好是你在负责这样的客户编码，我，很同情你。重构吧，老兄。
不满意，好，我们做第一次修改，根据DIP原则，我们提取这三个类的抽象。比如IClass, 然后，大家都实现他。然后，把ClassA a = new ClassA(); 改为IClass a = new ClassA();OK，很好的遵循了DIP原则。然后，我们需要有一个参与者，我称该类为Context或(Manager,mediator)，它的职责很简单，仅仅负责半黑盒子的组装。我们没有给予他过多的职责。SRP的违反同样让人觉得可怕。并把IClass作为一个委托对象属性传递给它。结构图如下：

这样，客户很轻松的从半黑盒子的策略组织中脱离出来，它只管在Context与这三个类之间进行装配，而装配的方式，你可以自由选择任何一种注入方式。例如：
你给Context装配一个ClassB。
Context context = new Context(new ClassB());
OK，针对于不稳定性因素的解决方案的基础结构出来了。这也是基于委托的设计模式的基础。这样的模型具有潜在的进化与退化问题。
1.Context是个具体类，具有不稳定性，有着往抽象方向的进化。
2.A线上是个委托属性。有着往临时委托方向的退化。
3.B线上create过程有从客户向Context转移的变化性。
4.Context的组织权有着向IClass转移的可能性。
在下面的继续中，我们会从基本型中根据这四个进化与退化以及委托的意义，演变出不同的模式。同时，我会把各个模式自身的进化与退化做个简介（自身的演化可能演变成别的模式）
等待继续.....

zhqh 2008-08-14 12:54 发表评论

语源科技BlogJava-myjava

设计模式之进化论(1)