無為則可為,無為則至深!
Flyweight在拳擊比賽中指最輕量級,即"蠅量級",有些作者翻譯為"羽量級"。這里使用"享元模式"更能反映模式的用意。
享元模式以共享的方式高效地支持大量的細粒度對象。享元對象能做到共享的關(guān)鍵是區(qū)分內(nèi)蘊狀態(tài)(Internal State)和外蘊狀態(tài)(External State)。內(nèi)蘊狀態(tài)是存儲在享元對象內(nèi)部并且不會隨環(huán)境改變而改變。因此內(nèi)蘊狀態(tài)并可以共享。
外蘊狀態(tài)是隨環(huán)境改變而改變的、不可以共享的狀態(tài)。享元對象的外蘊狀態(tài)必須由客戶端保存,并在享元對象被創(chuàng)建之后,在需要使用的時候再傳入到享元對象內(nèi)部。外蘊狀態(tài)與內(nèi)蘊狀態(tài)是相互獨立的。
享元模式的應(yīng)用
享元模式在編輯器系統(tǒng)中大量使用。一個文本編輯器往往會提供很多種字體,而通常的做法就是將每一個字母做成一個享元對象。享元對象的內(nèi)蘊狀態(tài)就是這個字母,而字母在文本中的位置和字模風(fēng)格等其他信息則是外蘊狀態(tài)。比如,字母a可能出現(xiàn)在文本的很多地方,雖然這些字母a的位置和字模風(fēng)格不同,但是所有這些地方使用的都是同一個字母對象。這樣一來,字母對象就可以在整個系統(tǒng)中共享。
在單純享元模式中,所有的享元對象都是可以共享的。單純享元模式所涉及的角色如下:
抽象享元(Flyweight)角色:此角色是所有的具體享元類的超類,為這些類規(guī)定出需要實現(xiàn)的公共接口。那些需要外蘊狀態(tài)(External State)的操作可以通過調(diào)用商業(yè)方法以參數(shù)形式傳入。
具體享元(ConcreteFlyweight)角色:實現(xiàn)抽象享元角色所規(guī)定的接口。如果有內(nèi)蘊狀態(tài)的話,必須負責(zé)為內(nèi)蘊狀態(tài)提供存儲空間。享元對象的內(nèi)蘊狀態(tài)必須與對象所處的周圍環(huán)境無關(guān),從而使得享元對象可以在系統(tǒng)內(nèi)共享的。
享元工廠(FlyweightFactory)角色:本角色負責(zé)創(chuàng)建和管理享元角色。本角色必須保證享元對象可以被系統(tǒng)適當(dāng)?shù)毓蚕怼.?dāng)一個客戶端對象調(diào)用一個享元對象的時候,享元工廠角色會檢查系統(tǒng)中是否已經(jīng)有一個復(fù)合要求的享元對象。如果已經(jīng)有了,享元工廠角色就應(yīng)當(dāng)提供這個已有的享元對象;如果系統(tǒng)中沒有一個適當(dāng)?shù)南碓獙ο蟮脑挘碓S角色就應(yīng)當(dāng)創(chuàng)建一個合適的享元對象。
客戶端(Client)角色:本角色需要維護一個對所有享元對象的引用。本角色需要自行存儲所有享元對象的外蘊狀態(tài)。
單純享元模式中,所有的享元對象都可以直接共享。下面考慮一個較為復(fù)雜的情況,即將一些單純享元使用合成模式加以復(fù)合,形成復(fù)合享元對象。這樣的復(fù)合享元對象本身不能共享,但是它們可以分解成單純享元對象,而后者則可以共享。
復(fù)合享元模式的類圖如下圖所示:
享元模式所涉及的角色有抽象享元角色、具體享元角色、復(fù)合享元角色、享員工廠角色,以及客戶端角色等。
抽象享元角色:此角色是所有的具體享元類的超類,為這些類規(guī)定出需要實現(xiàn)的公共接口。那些需要外蘊狀態(tài)(External State)的操作可以通過方法的參數(shù)傳入。抽象享元的接口使得享元變得可能,但是并不強制子類實行共享,因此并非所有的享元對象都是可以共享的。
具體享元(ConcreteFlyweight)角色:實現(xiàn)抽象享元角色所規(guī)定的接口。如果有內(nèi)蘊狀態(tài)的話,必須負責(zé)為內(nèi)蘊狀態(tài)提供存儲空間。享元對象的內(nèi)蘊狀態(tài)必須與對象所處的周圍環(huán)境無關(guān),從而使得享元對象可以在系統(tǒng)內(nèi)共享。有時候具體享元角色又叫做單純具體享元角色,因為復(fù)合享元角色是由單純具體享元角色通過復(fù)合而成的。
復(fù)合享元(UnsharableFlyweight)角色:復(fù)合享元角色所代表的對象是不可以共享的,但是一個復(fù)合享元對象可以分解成為多個本身是單純享元對象的組合。復(fù)合享元角色又稱做不可共享的享元對象。
享元工廠(FlyweightFactoiy)角色:本角色負責(zé)創(chuàng)建和管理享元角色。本角色必須保證享元對象可以被系統(tǒng)適當(dāng)?shù)毓蚕怼.?dāng)一個客戶端對象請求一個享元對象的時候,享元工廠角色需要檢查系統(tǒng)中是否已經(jīng)有一個符合要求的享元對象,如果已經(jīng)有了,享元工廠角色就應(yīng)當(dāng)提供這個已有的享元對象;如果系統(tǒng)中沒有一個適當(dāng)?shù)南碓獙ο蟮脑挘碓S角色就應(yīng)當(dāng)創(chuàng)建一個新的合適的享元對象。
客戶端(Client)角色:本角色還需要自行存儲所有享元對象的外蘊狀態(tài)。
注:由于復(fù)合享元模式比較復(fù)雜,這里就不再給出示意性代碼。通過將享元模式與合成模式組合在一起,可以確保復(fù)合享元中所包含的每個單純享元都具有相同的外蘊狀態(tài),而這些單純享元的內(nèi)蘊狀態(tài)往往不同。該部分內(nèi)容可以參考《Java與模式》第31章內(nèi)容。
在這個咖啡攤(Coffee Stall)所使用的系統(tǒng)里,有一系列的咖啡"風(fēng)味(Flavor)"。客人到攤位上購買咖啡,所有的咖啡均放在臺子上,客人自己拿到咖啡后就離開攤位。咖啡有內(nèi)蘊狀態(tài),也就是咖啡的風(fēng)味;咖啡沒有環(huán)境因素,也就是說沒有外蘊狀態(tài)。如果系統(tǒng)為每一杯咖啡都創(chuàng)建一個獨立的對象的話,那么就需要創(chuàng)建出很多的細小對象來。這樣就不如把咖啡按照種類(即"風(fēng)味")劃分,每一種風(fēng)味的咖啡只創(chuàng)建一個對象,并實行共享。
使用咖啡攤主的語言來講,所有的咖啡都可按"風(fēng)味"劃分成如Capucino、Espresso等,每一種風(fēng)味的咖啡不論賣出多少杯,都是全同、不可分辨的。所謂共享,就是咖啡風(fēng)味的共享,制造方法的共享等。因此,享元模式對咖啡攤來說,就意味著不需要為每一份單獨調(diào)制。攤主可以在需要時,一次性地調(diào)制出足夠一天出售的某一種風(fēng)味的咖啡。
很顯然,這里適合使用單純享元模式。系統(tǒng)的設(shè)計如下:
Copyright @ 草兒 Powered by: .Text and ASP.NET Theme by: .NET Monster