這次這個主題還是關于設計模式的，在早期的一篇已經(jīng)寫了，一直到現(xiàn)在還沒繼續(xù)完成他。而為什么又寫這主題呢？因為，這跟前面的主題確有不同之處，這回主要闡述了設計模式的進化問題。
到了今天，終于有點時間完成這主題了...
目錄結構：
1.基本概念
2.基礎結構
3.基于基礎結構的模式演化過程
其實這樣的層次是很簡單了，在基礎結構誕生之后，基于委托的模式已經(jīng)算是很明了的了。然后，大概介紹幾個基于委托的模式的演化過程
1.基本概念
這里列出了幾個相關概念。
委托
臨時委托
DIP原則
客戶
中介者（我叫它為管理器和調度器，當然，在不同模式中，取名有所差別）
目標對象
2.基本結構
編程中，當你需要某種服務，你當然會去調用具有該服務的目標對象（有可能是更高層次的組件），很顯然，結果，就是這樣一個的結構。client調用ClassA來實現(xiàn)某種服務。

比如，為了處理字符串，你會new String，然后進行一些處理。甚至，你的代碼里到處都充砌著String的足跡，這樣確實能很好的解決問題。這樣的結構背后的理由呢？首先，我想說的是，這樣的結構違反了DIP原則，細節(jié)應該依賴于抽象，而不是依賴于另一個細節(jié)。這樣的依賴關系會使代碼缺乏彈性，很難復用，遷一發(fā)動全身。應該改進的是，把ClassA的抽象提取出來，然后讓client去依賴于IClassA,變成如下圖： 
 

但是，事實上，我們沒有這么做。這是因為String這樣的類實例具有很強的穩(wěn)定性，這樣的穩(wěn)定性保證了它不會經(jīng)常變化，這就是行為的穩(wěn)定性因素。這樣具有強穩(wěn)定性的類沒必要復雜化。所以，我們讓接受了client依賴于細節(jié)的結果。這樣的細節(jié)是單一的。
然而，需求是變化的，解決方案是不穩(wěn)定的，在我們的項目中，會有大量不具穩(wěn)定性的因素存在。在項目中，你會發(fā)現(xiàn)存在著多個同性質而實現(xiàn)細節(jié)有異的行為類存在。
比如存在著這樣的三個類ClassA,ClassB, ClassC,
client在不同地方調用它。結構圖如下： 
 

我假設client是個main函數(shù)，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)    }

}
這樣的代碼，給你的感覺怎么樣，也許還蠻過得去，他確實是跑得起來。但這樣的代碼存在潛在的危險性。應該被歸入糟糕設計的范疇里。首先，客戶面對不具穩(wěn)定性的因素，根據(jù)DIP原則，它沒有提取抽象，違反了DIP原則。其次，client（main）必須負責策略的組織(我把類似(1)(2)(3)(4)的目標對象的這樣一組調用過程稱為策略組織),也就是說，client面對的不是一個完全的黑盒子，他面對的是一些半黑的盒子，同時，他必須知道怎么把這些半黑的盒子組裝起來。例如(5)(6)(7)(8)這些對客戶來說，是一組半黑的盒子。客戶本身的任務太重了，同時，這樣的任務彌漫在客戶的頭和腳之間，及其零亂。很快，又有類似的另一種不具穩(wěn)定性的因素參與這樣的彌漫活動，最終的客戶將被淹沒在不穩(wěn)定性因素組成的大海里。如果，剛好是你在負責這樣的客戶編碼，我，很同情你。重構吧，老兄。
不滿意，好，我們做第一次修改，根據(jù)DIP原則，我們提取這三個類的抽象。比如IClass, 然后，大家都實現(xiàn)他。然后，把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，針對于不穩(wěn)定性因素的解決方案的基礎結構出來了。這也是基于委托的設計模式的基礎。這樣的模型具有潛在的進化與退化問題。
1.Context是個具體類，具有不穩(wěn)定性，有著往抽象方向的進化。
2.A線上是個委托屬性。有著往臨時委托方向的退化。
3.B線上create過程有從客戶向Context轉移的變化性。
4.Context的組織權有著向IClass轉移的可能性。
在下面的繼續(xù)中，我們會從基本型中根據(jù)這四個進化與退化以及委托的意義，演變出不同的模式。 同時，我會把各個模式自身的進化與退化做個簡介（自身的演化可能演變成別的模式）
等待繼續(xù).....