繼續(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變吧。它逃不了的。
也許休息的時間到了，我會盡量再接下來的幾天內，把這東西寫完成的.....
待續......