继续(2)
主要模式：iterator, adater, chain of responsibility, builder, proxy, decorator, (template)strategy, bridge, state, visitor,observer, command, mediator
7.template(继承与多态)
template算是继承概念里的一个模式，这里提前说了，因为，我认为，他跟strategy有类似之处，所以提前。这结构很简单，主要利用了面向对象的多态特性，抽象类定义的具体实现绑定到派生类，而父类提供了一个模板，来组织全部或部分的结构，从而提供了具有某种普遍一样的行为。具体代码如下：
abstract class AbstractClass{
    public void templateMethod(){
       method1();
       method2();
   }
   abstract public void method1();
   abstract public void method2();
}
class ConcreteClass extends AbstractClass{
   public void method1(){
   }
   public void method2(){  
   }
}
void main(){
   AbstractClass abstractClass = new ConcreteClass();
   abstractClass.templateMethod();
}
8.strategy(单向简单委托)：但是，如果你在设计中发现，这种高度耦合的结构解决不了你的问题，那么我会推荐采用另一种方案---strategy。该方案同样使用委托，它把通用模板放到了一个独立的类中，给该类注入一个被委托对象实例，然后模板的每一个执行步骤，交给被委托者一一执行。看例子：
class Strategy{
     public void method1(){
     }
     public void method2(){
     }
}
class Context{
     private Strategy strategy;
     public Context(Strategy strategy){
        this.strategy = strategy;
     }
     public void algorithmMethod(){
        strategy.method1();
        strategy.method2();
     }
}
void main(){
    Context context = new Context(new Strategy());
    context.algorithmMethod();
}
也许，你看到这样的结构，在哪里？builder模式，对了，看起来，真象孪生兄弟。但是，区别在哪里呢？该模式侧重于算法，某一天，你想到新的改进算法，你完全可以替换该strategy，我想你记得，本文到头到尾都再依赖具体类，Context里的Strategy本该是接口或抽象类的。真正设计时，我们会考虑这点。而对于，builder侧重于建造步骤，当然，如果，哪天你如果突然觉得有一种方式能够更好的建造房屋，那你就去改进房屋的建造细节吧。
9.bridge(单向简单委托)
10.state(单向简单委托)
11.visitor(无任何委托)
我说没任何委托，因为，我没发现，委托者手里揣这被委托者，同时被委托者手里也毫无东西。然而，我还是说它是一种委托，而且是双向简单委托。或许我该把类似这样的无任何委托的东西定义为临时委托。以下我将展示一个从双向简单委托到临时委托的演变过程。当然，我会以雇主和保姆的例子来说明它。因为构造
class Element{
    Visitor v;
    setVisitor(Visitor v){
        this.v = v;
    }
    accept(){
        v.visit();
    }
}
class Visitor{
    Element e;
    setElement(Element e){
        this.e = e;
    }
    visit(){
        访问e的过程。    
    }
}
void main(){
    Element e = new Element();          
    Visitor v = new Visitor();
    e.setVisitor(v);    //建立双向委托关系
    v.setElement(e);
    e.accept();
}
对于这段代码，我想说明几点：
Element: 表示雇主。
Visitor：表示保姆。
accept：表示雇主让保姆扫地的要求。//至少，扫地是我沿用一开始的感觉，其实，这个形象的描述是我一个好朋友想的，在此表示感谢。当时，我问他有没好例子来描述我给他讲的想法。
visit: 表示保姆扫地过程，当然他需要雇主的扫把和其他一些东西
OK，到现在为止，这代码能正常工作了，他解决了雇主雇用保姆扫地的问题。
让我们理清下逻辑，先是来了一个雇主和一个保姆，然后，雇主要了保姆的资料，同时保姆也要了雇主的资料，这种劳动关系就这么建立了，当雇主要求扫地时即e.accept()，他委托他持有的保姆来干活，而保姆visit()，他无任何参数，因为他也持有雇主了。然而，保姆很懒--你见过保姆很勤快的吗？他告诉雇主，我不想记那么多，你叫扫地时，把你的信息一起携带给我。为什么呢？因为保姆他也想多赚钱，这样方式，他可以为多个雇主服务，得到可观的收入。
于是，出现了下面的改写。
class Element{
    Visitor v;
    Element(Visitor v){
        this.v = v;
    }
    accept(){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问e的过程。    
    }
}
void main(){
    Visitor v = new Visitor();
    Element e = new Element(v);          
    e.accept();
}
这些新代码，意味着保姆有了新的工作方式，他可以为多个雇主工作，而雇主呢？看到委托了，哦，他只能雇佣一个保姆。你觉得这样如何，我想说的是，如果你想长期雇佣这个保姆，OK，它可以很好的为你工作。
这种方式，一直工作的好好的，保姆很勤劳，雇主也很友善。但是，你可曾想过，哪一天，只要关系中的任何一方翻脸，这将是一大灾烂，双方纠缠不清。所以，雇主有了经验，他不想在第二关卡结束游戏，所以，他决定找一个临时工。更具体的说，他想需要扫地时才去请保姆(但是，他有可能一时半会找不到，这个不管他)，于是，他把保姆的委托也丢掉了，他不再只让固定保姆做事了。OK，他把委托提到参数的位置去了。
class Element{
    accept(Visitor v){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问e的过程。    
    }
}
void main(){
    Visitor v = new Visitor();
    Element e = new Element();          
    e.accept(v);
}
这样的结果，雇主可以请临时保姆干活，保姆也可以为多个雇主服务，很满意，我们稍微修改成下面。
class Element1{
    accept(Visitor v){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问雇主e的过程。    
    }
    visit(Element1 e1){        访问雇主e的过程。    
    }
}
OK，这样的结果，不会变了吗？当然，我们会尽量保持住，代码写了可不能乱动。但是，有一天，城市里又来了新雇主Element2，保姆为了能为他服务，怎么办，添加visit(Element2 e2)？我建议别这么做，为什么？你违反了游戏规则(OCP)，但是，他对于固定数据结构的具体访问非常有用，如果，他很好的帮助你解决问题，那就用它吧。这个例子，引出了临时委托的概念，那什么时候，会使用它呢？我想说的是，如果委托者要做的事很多，且都是交给被委托者，也就是，委托者与被委托者的交付是频繁的，那么我建议，你保持住这个长期工(对象变量)，除此之外，你会很喜欢找临时工的。这个临时是参数的形式出现在的。所以，所有委托方式的模式，都可以使用临时委托来实现。那为什么那么模式都保持了被委托者呢？我说了。这也提示了一点，所谓设计模式，不是一成不变的，是随着具体需要而发展的。也许，你哪天使用的就是某种设计模式的变形。理解本质，核心的东西，那就让它72变吧。它逃不了的。
也许休息的时间到了，我会尽量再接下来的几天内，把这东西写完成的.....
待续......