單純享元模式所涉及的角色如下：
抽象享元(flyweight)角色：此角色是所有的具體享元類的超類，為這些類規定出需要實現的公共介面。那些需要外蘊狀態(external state)的操作可以通過呼叫商業方法以引數形式傳入。
具體享元(concreteflyweight)角色：實現抽象享元角色所規定的介面。如果有內蘊狀態的話，必須負責為內蘊狀態提供儲存空間。享元物件的內蘊狀態必須與物件所處的周圍環境無關，從而使得享元物件可以在系統內共享的。
享元工廠(flyweightfactory)角色：本角色負責建立和管理享元角色。本角色必須保證享元物件可以被系統適當地共享。當乙個客戶端物件呼叫乙個享元物件的時候，享元工廠角色會檢查系統中是否已經有乙個復合要求的享元物件。如果已經有了，享元工廠角色就應當提供這個已有的享元物件；如果系統中沒有乙個適當的享元物件的話，享元工廠角色就應當建立乙個合適的享元物件。
客戶端(client)角色：本角色需要維護乙個對所有享元物件的引用。本角色需要自行儲存所有享元物件的外蘊狀態
在飯店裡,如果有菜譜所要的菜,就不用去買,直接去菜庫里去拿,如果沒有就要去買,然後放在菜庫里.
public inte***ce flyweight
public inte***ce people
public class food implements flyweight
public string getfoodname()
public void setfoodname(string foodname)
}public class kitchener implements people
}public class flyweightfactoy
return food;}}
public class testflyweight
}
享元模式應當在什麼情況下使用
當以下所有的條件都滿足時，可以考慮使用享元模式：
乙個系統有大量的物件。
這些物件耗費大量的記憶體。
這些物件的狀態中的大部分都可以外部化。
這些物件可以按照內蘊狀態分成很多的組，當把外蘊物件從物件中剔除時，每乙個組都可以僅用乙個物件代替。
軟體系統不依賴於這些物件的身份，換言之，這些物件可以是不可分辨的。
滿足以上的這些條件的系統可以使用享元物件。
最後，使用享元模式需要維護乙個記錄了系統已有的所有享元的表，而這需要耗費資源。因此，應當在有足夠多的享元例項可供共享時才值得使用享元模式。
享元模式的優點和缺點:
享元模式的優點在於它大幅度地降低記憶體中物件的數量。但是，它做到這一點所付出的代價也是很高的：
享元模式使得系統更加複雜。為了使物件可以共享，需要將一些狀態外部化，這使得程式的邏輯複雜化。
享元模式將享元物件的狀態外部化，而讀取外部狀態使得執行時間稍微變長。
FlyWeight設計模式
先做個比方 乙個停車場有1000輛車子,每輛車子都是乙個物件,每個物件例項占用記憶體0.1m,那麼總共點用100m 如果數量再多些10000,100000.系統記憶體很容易消耗完.我們可以看出這麼車子有很多是相同的,那麼是否可以用共享的方式來減少例項的數量呢?答案是肯定的,於是flyweight方式...
設計模式 結構型之享元 flyweight 模式
定義 使用場景 uml圖 實現 共享物件 public class flyweight public void method 池子工廠 public class flyweightfactory 公有獲取單例 public static flyweightfactory getfacttory 獲取...
C 設計模式 八 FlyWeight模式
問題 在物件導向的設計過程中，可能需要建立建立許多物件，而實際上這些物件沒有多大的區別，我們可以建立乙個物件，讓這許多物件共享乙個物件，當然這些物件可能會有些許屬性差異，我們可以通過調整這些屬性來達到我們的要求。這樣的好處是可以避免重複建立物件帶來空間和時間的浪費。uml 實現 需要說明的是下面的實...