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