亨元模式(flyweight Pattern)
可以理解成為輕量級模式,是一種軟體設計模式。
面向對象的思想很好地解決了抽象性的問題，一般也不會出現性能上的問題。但是在某些情況下，對象的數量可能會太多，從而導致了運行時的代價。那么我們如何去避免大量細粒度的對象，同時又不影響客戶程式使用面向對象的方式進行操作？
亨元模式結構圖圖1 Flyweight模式結構圖
1.亨元模式的用意
亨元模式是對象的結構模式。亨元模式以共享的方式高效地支持大量的細粒度對象。
亨元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態
一個內蘊狀態是存儲在亨元對象內部的，並且是不會隨環境改變而有所不同的。因此，一個亨元可以具有內蘊狀態並可以共享。
一個外蘊狀態是隨環境改變而改變的、不可以共享的狀態。亨元對象的外蘊狀態必須由客戶端保存，並在亨元對象被創建之後，
在需要使用的時候再傳入到亨元對象內部。
外蘊狀態不可以影響亨元對象的內蘊狀態的，它們是相互獨立的。
根據所涉及的亨元對象的北部表象，亨元模式可以分為單純亨元模式和複合亨元模式兩種形式。
3.亨元模式的實現1）單純亨元模式涉及的角色
1－抽象亨元角色：此角色是所有的具體亨元類的超類，為這些規定出需要實現的公共接口，那些需要外蘊狀態的操作
可以通過方法的參數傳入。抽象亨元的接口使得亨元變得可能，但是並不強制子類實行共享，因此並非所有的亨元
對象都是可以共享的
2－具體亨元角色：實現抽象亨元角色所規定的接口。如果有內蘊狀態的話，必須負責為內蘊狀態提供存儲空間。
亨元對象的內蘊狀態必須與對象所處的周圍環境無關，從而使得亨元對象可以在系統內共享。有時候具體亨元角色
又叫做單純具體亨元角色，因為複合亨元角色是由單純具體亨元角色通過複合而成的
3－複合亨元角色：複合亨元角色所代表的對象是不可以共享的，但是一個複合亨元對象可以分解成為多個本身是單純亨元
對象的組合。複合亨元角色又稱做不可共享的亨元對象。
4－亨元工廠角色：本角色負責創建和管理亨元角色。本角色必須保證亨元對象可以被系統適當地共享。
當一個客戶端對象請求一個亨元對象的時候，亨元工廠角色需要檢查系統中是否已經有一個符合要求的亨元對象，
如果已經有了，亨元工廠角色就應當提供這個已有的亨元對象；如果系統中沒有一個適當的亨元對象的話，
亨元工廠角色就應當創建一個新的合適的亨元對象。
5－客戶端角色：本角色還需要自行存儲所有亨元對象的外蘊狀態。
比如圍棋有300顆棋子,
用一般的設計模式,
創建一個類,
每個棋子都用一個對象的話
那就會非常麻煩，並且各自定義各自在棋盤的位置.....等等
而使用 亨元模式 來實現的話,
就用兩個對象:一個黑,一個白。
這樣就可以了,至於棋子的方位不同,那只是對象的不同的外部表現形式或者說是外部狀態。
這樣三百多個對象就減到了兩個對象。
享元模式以共享的方式高效地支持大量的細粒度對象,
說的再具體一些是將所有具有相同狀態的對象指向同一個引用,
從而解決了系統在創建大量對象時所帶來的記憶體壓力。
享元模式套用較少,這裡再舉一個森林和樹木的例子來說明這個模式的套用。
一片森林中有成千上萬棵樹木,如果每棵樹都創建一個對象,那么記憶體中的對象數量相當龐大,更何況我們現實世界中還有成千上萬個森林。
此模式最大限度地減少了儘可能與其他類似的對象多的數據共享記憶體的使用,
這是一種利用大量對象時,一個簡單的重複表示將使用的記憶體接受的範圍。
這個詞來自於同名拳擊重量級別。
通常的對象狀態的某些部分可以共享,這很常見的結構,把外部數據並傳遞給了輕量級的對象時,暫時使用。
以上的這些例子 說明了亨元模式,以減少使用只載入必要的數據,記憶體來執行從一個大字型對象的某些緊迫任務到更小FontData（輕量級）對象。
