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