白話設計模式–結構型模式–組合模式,橋接模式和適配器模式

轉眼間,設計模式已經學了這麼多了.

我覺得,設計模式其實就是如何抽象的更合理,如何讓使用和實現分離.這些做法讓我們的軟體更容易的應對變化,如此而已.

 

前幾天學的橋接模式.

當變化面向兩個或以上的維度時，我們採用組合抽象的方法來應對變化。
什麼組合抽象呢？讓我們來看看橋接模式，你就知道了。

當一個對象，它可能發生兩種變化：A維度和B維度。那麼，我們就把A抽象出來叫做AbstractA,把B抽象出來叫做AbstractB。把它們組合起來，簡單說就是把AbstractB的一個執行個體放在AbstractA中。B變化是輔助的抽象，主邏輯再A中。獨立實現B的抽象以便以後使用 。在實現了AbstractA的具體執行個體中，我們就可以使用抽象B，而不去關心抽象B是怎麼實現的。只需要傳進去一個抽象B的具體實現執行個體就行了。在抽象A中，我們可以任意組合這兩個維度，這就解決了一個對象兩個維度劇烈變化的問題,就算它們縱橫交錯我們也不怕。
橋接模式的關鍵點和重點在與物件導向設計的原則：Prefer組合To繼承。實際上使用多繼承也是可以解決這些問題，但是並不是我們推薦的,這種多繼承往往違背單一職責原則。而且，C#不支援多繼承，所以必須繼承兩個介面。那麼，抽象A和抽象B就使平等的關係，而抽象B不是主要的，它本身也許並沒有什麼獨立的意義，這樣就搞混了類之間的關係。

 

那麼之前我學習了適配器模式,同樣作為結構型模式,適配器模式更多的用在匹配原有介面,以適應新的變化要求.對於使用者來說,原有的介面是黑盒的,不可見的.

而橋接模式更多的用在兩條線的變化需求上.在設計的初期,應對主邏輯和輔邏輯的變化,我們就用橋接模式,把輔邏輯介面組合到主邏輯介面中,然後讓他們分別去實現.

而在設計完成以後或者開發已經結束,發現現有的介面不能滿足需求,那麼我們就使用適配器模式,建立新的介面適配原介面以滿足需求.

 

經過學習和實踐,我們也可以瞭解到,這兩個模式(bridge and adaptor)也經常一起使用.比如如下這個情境:橋接模式中的輔邏輯的某個實現需要使用某個外部介面,那麼此時就可以把那個外部介面適配到這個實現中來,如此便同時使用了bridge和adaptor.說的有點兒抽象,不知道大家能不能理解,因為我沒有找到太好的關於這方面的例子,如果哪位同志有,請千萬拿出來和大家分享.

 

今天學的組合模式,覺得簡單得沒法再簡單了.

但是,聽說這可是使用的非常多的,特別有用的一個模式.所以各位也不要看輕了.組合模式,從名字就可以看出來,是把某種東西組合起來了.

那麼為什麼要組合起來呢?

就是為了更方便的調用.調用方(用戶端)不管你是組合起來的還是單個的,統統都調用一個介面的方法.而Container(容器)包含了單個的SingleObject,不管是Container還是SingleObject都實現同一個介面,用戶端只需要調用這個介面就可以了.在Container中,迴圈調用SingleObject以及它的方法,這樣,介面同一,方便了用戶端調用,簡化了用戶端代碼,此時用戶端已經不需要知道你是個Container 還是個SingleObject,反正都一樣的介面.

 

一個公司的下面的所有的部門就是一個很好的例子.

總經理說:我要知道這個月的各個部門的工作.那麼每個部門都應該呈交到秘書處一個報表,然後秘書匯總後交給總經理.

那麼,如果我們沒有使用組合模式,意思就是需要總經理一個一個部門的去問:你們部門這個月怎麼樣啊?會把他累死.

使用了組合模式,總經理就是個Client,它不需要關心各部門的報告(SingleObject)是怎麼組合的,只看秘書處(介面)的匯總的東西就可以了.秘書處匯總在一起的報告(Container容器),直接交給總經理看.

 

例子舉的又不合適的地方,還請各位務必指出,以便大家共同學習.初學者發表的東西有很多地方並不一定是對的,但是希望能給大家一些啟發,讓我們共同思考,完成軟體設計開發大業,謝謝.:)