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

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

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

我假設(shè)client是個(gè)main函數(shù)，OK，調(diào)用的代碼應(yīng)該是這樣，
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)    }

}
這樣的代碼，給你的感覺怎么樣，也許還蠻過得去，他確實(shí)是跑得起來。但這樣的代碼存在潛在的危險(xiǎn)性。應(yīng)該被歸入糟糕設(shè)計(jì)的范疇里。首先，客戶面對(duì)不具穩(wěn)定性的因素，根據(jù)DIP原則，它沒有提取抽象，違反了DIP原則。其次，client（main）必須負(fù)責(zé)策略的組織(我把類似(1)(2)(3)(4)的目標(biāo)對(duì)象的這樣一組調(diào)用過程稱為策略組織),也就是說，client面對(duì)的不是一個(gè)完全的黑盒子，他面對(duì)的是一些半黑的盒子，同時(shí)，他必須知道怎么把這些半黑的盒子組裝起來。例如(5)(6)(7)(8)這些對(duì)客戶來說，是一組半黑的盒子。客戶本身的任務(wù)太重了，同時(shí)，這樣的任務(wù)彌漫在客戶的頭和腳之間，及其零亂。很快，又有類似的另一種不具穩(wěn)定性的因素參與這樣的彌漫活動(dòng)，最終的客戶將被淹沒在不穩(wěn)定性因素組成的大海里。如果，剛好是你在負(fù)責(zé)這樣的客戶編碼，我，很同情你。重構(gòu)吧，老兄。
不滿意，好，我們做第一次修改，根據(jù)DIP原則，我們提取這三個(gè)類的抽象。比如IClass, 然后，大家都實(shí)現(xiàn)他。然后，把ClassA a = new ClassA(); 改為IClass a = new ClassA();OK，很好的遵循了DIP原則。然后，我們需要有一個(gè)參與者，我稱該類為Context或(Manager,mediator)，它的職責(zé)很簡(jiǎn)單，僅僅負(fù)責(zé)半黑盒子的組裝。我們沒有給予他過多的職責(zé)。SRP的違反同樣讓人覺得可怕。并把IClass作為一個(gè)委托對(duì)象屬性傳遞給它。結(jié)構(gòu)圖如下： 
 

這樣，客戶很輕松的從半黑盒子的策略組織中脫離出來，它只管在Context與這三個(gè)類之間進(jìn)行裝配，而裝配的方式，你可以自由選擇任何一種注入方式。例如：
你給Context裝配一個(gè)ClassB。
Context context = new Context(new ClassB());
OK，針對(duì)于不穩(wěn)定性因素的解決方案的基礎(chǔ)結(jié)構(gòu)出來了。這也是基于委托的設(shè)計(jì)模式的基礎(chǔ)。這樣的模型具有潛在的進(jìn)化與退化問題。
1.Context是個(gè)具體類，具有不穩(wěn)定性，有著往抽象方向的進(jìn)化。
2.A線上是個(gè)委托屬性。有著往臨時(shí)委托方向的退化。
3.B線上create過程有從客戶向Context轉(zhuǎn)移的變化性。
4.Context的組織權(quán)有著向IClass轉(zhuǎn)移的可能性。
在下面的繼續(xù)中，我們會(huì)從基本型中根據(jù)這四個(gè)進(jìn)化與退化以及委托的意義，演變出不同的模式。 同時(shí)，我會(huì)把各個(gè)模式自身的進(jìn)化與退化做個(gè)簡(jiǎn)介（自身的演化可能演變成別的模式）
等待繼續(xù).....