2004-08-30
結(jié)構(gòu)型模式：描述的是一系列將類和對象進行組合，以構(gòu)建更大的類和對象。其強調(diào)的是結(jié)構(gòu)化的方式，而不是怎樣去構(gòu)造這些類。
結(jié)構(gòu)型模式分為兩種：
a、結(jié)構(gòu)型類模式：通過接口或類的繼承來實現(xiàn)。
b、結(jié)構(gòu)型對象模式：不是對類或接口，而是對對象進行組合。
/*****************************************************************************************/
1、Adapter(適配器)/wrapper(包裝器)
適配模式最重要的作用是去將已有的、但是接口不兼容的東西接入到系統(tǒng)中來。進行復(fù)雜邏輯程序的有效重用。
這個模式中adaptor,adaptee的基類是具有惟一性的。
a、類適配
類適配就是通過繼承這種靜態(tài)的方式來進行適配，也就是適配器會繼承需要被適配的東西，
缺點是適配的范圍比較小，不能滿足同時適配一組對象（類及其子類）的要求。
b、對象適配
對象適配：適配器并不會靜態(tài)的繼承，而會是采用引用需要被適配類的方式，這樣，被適配類及其子類都可以被適配了，
缺點：需要動態(tài)的指定被適配對象，而且容易引起運行期錯誤
注：可能是對于其他面向?qū)ο笳Z言的不了解，我覺得用對象適配就可以了，沒有必要使用類適配的模式，對于只有一個需要適配的類的情況，我們只需要將動態(tài)構(gòu)造引用對象的過程加在適配器的構(gòu)造函數(shù)中就可以了，在今后對其他類型的OO語言有了了解之后，可以再回顧一下此處。
/*****************************************************************************************/
2、bridge(橋接)/(Handle/boby)－－－結(jié)構(gòu)型對象模式
橋接的模式最重要的作用是將抽象/表現(xiàn)與實現(xiàn)相分離，保持程序良好的可擴展性。
這個模式中window和windowimpl這兩個接口是具有惟一性的。
一個一般的繼承模式的設(shè)計
window--xwindow
?pmwindow
?iconwindow--pmiconwindow
????? xiconwindow
這種樹狀的繼承方式將抽象的表現(xiàn)部分iconwindow和抽象的實現(xiàn)部分(xwindow,pmwindow)集成到了一起。
而這兩者其實負責(zé)不同的東西，一是表現(xiàn)(外部特征，如icon是可以拖拽的，是由矩形組成的等等)，二是具體實現(xiàn)平臺，負責(zé)在xwindow風(fēng)格下的線如何畫，線有多粗，從什么位置開始畫等等。
于是應(yīng)該有著兩條線的結(jié)構(gòu)：
window--iconwindow
?applicationwindow
windowimpl--xwindow
???? pmwindow
中間通過window對windowimpl的引用來達到橋接的作用，也就是說，橋接的奧秘就在于此，合理的將這兩者的接口進行分離，是橋接模式設(shè)計的關(guān)鍵。
橋接方式的退化形式就是我們只是需要實現(xiàn)xwindow或者pmwindow中的一種，這樣windowimpl就失去意義了。（對于有些語言，windowimpl的存在可能有利于實現(xiàn)的改變不需要重新編譯客戶應(yīng)用程序）??
/*****************************************************************************************/
3、composite(組合)－－－結(jié)構(gòu)型對象模式
組合模式使得單個對象和組合對象的使用具有一致性。使得對外提供的接口變得單一，用戶忽略單個對象與組合對象的差異。
組合模式著力于解決這樣一個矛盾：
在一個程序組中有著層次的關(guān)系，需要表現(xiàn)（這是一個內(nèi)部重用性和易讀性的問題）
但是這個程序組中的對象有著共性，并且希望外部調(diào)用程序忽視其各異性而只是關(guān)注其共性的部分（這是一個外部接口簡單化的問題）。
所以其主要元素的關(guān)系就是這樣了：
composite(復(fù)合對象)-leaf(簡單對象)
????? composite(復(fù)合對象)-leaf(簡單對象)
?????leaf(簡單對象)
而這些對象實現(xiàn)統(tǒng)一的接口或者抽象類：compositeInterface;任何client對任何對象實例的操作都是通過接口進行。
模式的實現(xiàn)：
在實現(xiàn)中會有一系列的問題，這只是實現(xiàn)的問題，和模式本身無關(guān)。
1、顯示父對象引用：解決方法：建立一個穩(wěn)定，模式化的父子引用關(guān)系和操作方法。
2、共享組件：這將父子之間的1：N的關(guān)系變成了N：N的模式，參考flyweight模式。
3、最大化component接口：這是保證操作透明化的必須，我們應(yīng)該盡力達到這個目的。
4、聲明管理子部件的操作：這個問題最大的麻煩來源于子部件和父部件最大的差異－－有沒有子節(jié)點，可以通過統(tǒng)一的，技巧性的add,remove方法來完成。
5、compositeInterface是否應(yīng)該實現(xiàn)一個compositeInterface列表：這是一個關(guān)于存儲的問題，就是對于子節(jié)點的引用對于葉子節(jié)點是無意義的內(nèi)存消耗。
6、子部件排序：Iterator模式應(yīng)該有一定的作用。
7、高速緩存改善性能。
/*****************************************************************************************/
4、decorator(裝飾)/包裝器(wrapper)－－－結(jié)構(gòu)型對象模式
從名字我們就可以看出這個模式的基本立意：一位畫家畫完一幅畫（實現(xiàn)一個組件）之后，并不需要自己去做畫框（decorator）,做這個畫框就是這個模式需要解決的問題。
可以看到畫框能為畫家所用是基于一種前提的，就是畫家的用紙和畫框的大小是符合的，也是基于一種結(jié)果，就是畫還是畫，不會因為畫框而改變其畫的本質(zhì)和內(nèi)容，只是現(xiàn)在是一幅有框的畫了。
回到模式中，我們可以看到這個模式的大概了：
component(組件接口)－concreteComponent(組件實現(xiàn))
???? －decorator(裝飾器)－－>m_cmp(對組件實現(xiàn)的引用)
這里我們可以看到decorator模式和adaptor模式的區(qū)別，decorator著力于裝飾器部分的重用，而adaptor只是著力于組件的重用。decorator著力于封裝組件的可以插件化的共性特征，其著眼點是組件級別以下的功能重用。adaptor著眼的還是組件一級的功能重用。
/*****************************************************************************************/
在前面的composite和decorator模式中，我們不停的追求將組件實現(xiàn)得更加的細粒度化，以便增加組件的可重用性，這基本是各種良好設(shè)計的共同特征。
但是這種設(shè)計方式也會導(dǎo)致各種問題，其中就包括零散、以及大量對象實例導(dǎo)致的資源消耗問題。
/*****************************************************************************************/
5、facade(外觀)－－結(jié)構(gòu)型對象模式
facade模式最大的特點就是將復(fù)雜、零散的子系統(tǒng)進行唯一入口的封裝。
這種模式在我經(jīng)歷的系統(tǒng)印象最深的就是多層分層的層層之間的接口上，一個唯一的入口，讓層次非常的清晰。
其實這種模式與adaptor有一定的相似之處，都是屏蔽兩個不同的子系統(tǒng)，但是不同的是，facade是主動的構(gòu)建，而adaptor是為了接入其他的系統(tǒng)而被動的構(gòu)建的，可以看出，要對一個已經(jīng)實現(xiàn)了facade模式的子系統(tǒng)構(gòu)建adaptor遠比沒有沒有實現(xiàn)facade模式的要簡單的多，代價要小得多。
/*****************************************************************************************/
6、flyweight(享元)－－結(jié)構(gòu)型對象模式
享元設(shè)計模式著力解決的就是當(dāng)內(nèi)存中存在大量同樣的對象實例導(dǎo)致的資源消耗問題。
可以幾個方面來理解，
享元模式追求的是實例級別的重用。
將外部狀態(tài)（上下文）和對象實例本身分離，不是在構(gòu)建時傳入外部狀態(tài)，而是在運行期，甚至這種狀態(tài)完全是過程性的，和對象實例沒有關(guān)系。而內(nèi)部狀態(tài)只在創(chuàng)建時指定，而在運行期是絕對不可以碰的。
這種模式與原型模式的最大區(qū)別在于，一個共享實例級別的，一個是共享類的級別。
/*****************************************************************************************/
6、proxy(代理)/surrogate－－結(jié)構(gòu)型對象模式
常見使用情況
1、遠程代理（remote proxy）
2、虛代理(virtual proxy)：根據(jù)需要創(chuàng)建開銷很大的對象。
3、保護代理（protection proxy）：控制對原始對象的訪問。
4、智能指引（smart refrence）：取代簡單指針，便于在訪問對象前做些附加操作。
這種代理使用廣泛，什么copy_on_write,lazy_loading等技術(shù)都可以考慮這種方式的實現(xiàn)。
proxy模式代理和被代理對象接口是一致的或者是子集，但adaptor模式則不同。
decorator模式為對象增加接口，而proxy是轉(zhuǎn)發(fā)或者限制接口。