享元模式英文稱為「flyweight pattern」，又譯為羽量級模式或者蠅量級模式。
享元模式的定義為：採用乙個共享類來避免大量擁有相同內容的「小類」的開銷。這種開銷中最常見、直觀的影響就是增加了記憶體的損耗。享元模式以共享的方式高效的支援大量的細粒度物件，減少其帶來的開銷。
在名字和定義中都體現出了共享這乙個核心概念，那麼怎麼來實現共享呢？事物之間都是不同的，但是又存在一定的共性，如果只有完全相同的事物才能共享，那麼享元模式可以說就是不可行的；因此我們應該盡量將事物的共性共享，而又保留它的個性。為了做到這點，享元模式中區分了內蘊狀態和外蘊狀態。內蘊狀態就是共性，外蘊狀態就是個性了。
內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同，是可以共享的；外蘊狀態是不可以共享的，它隨環境的改變而改變的，因此外蘊狀態是由客戶端來保持（因為環境的變化是由客戶端引起的）。在每個具體的環境下，客戶端將外蘊狀態傳遞給享元，從而建立不同的物件出來。
先從簡單的入手，看看單純享元模式的結構。
1) 抽象享元角色：為具體享元角色規定了必須實現的方法，而
外蘊狀態就是以引數的形式通過此方法傳入。
2) 具體享元角色：實現抽象角色規定的方法。如果存在內蘊狀態，就負責為內蘊狀態提供儲存空間。
3) 享元工廠角色：負責建立和管理享元角色。
要想達到共享的目的，這個角色的實現是關鍵！
4) 客戶端角色：維護對所有享元物件的引用，而且還需要儲存對應的外蘊狀態。
未完待續……
享元模式優點就在於它能夠大幅度的降低記憶體中物件的數量；而為了做到這一步也帶來了它的缺點：它使得系統邏輯複雜化，而且在一定程度上外蘊狀態影響了系統的速度。所以一定要切記使用享元模式的條件：
1)系統中有大量的物件，他們使系統的效率降低。
2)這些物件的狀態可以分離出所需要的內外兩部分。
外蘊狀態和內蘊狀態的劃分以及兩者關係的對應也是非常值得重視的。只有將內外劃分妥當才能使內蘊狀態發揮它應有的作用；如果劃分失誤，在最糟糕的情況下系統中的物件是乙個也不會減少的！兩者的對應關係的維護和查詢也是要花費一定的空間（當然這個比起不使用共享物件要小得多）和時間的，可以說享元模式就是使用時間來換取空間的。可以採用相應的演算法來提高查詢的速度。
設計模式之享元模式
1 享元模式運用共享技術有效地支援大量細粒度的物件。uml圖如下 2 思考 flyweight根據客戶需求返回已經生成好的物件，但一定要事先生成物件例項嗎？答 實際上是不一定需要的，完全可以初始化的時候什麼也不做，到需要的時候，再去判斷物件是否為null來決定是否例項化。3 思考 為什麼要有unsh...
設計模式之享元模式
享元模式運用共享技術有效地支援大量細粒度的物件。如果乙個應用程式使用了大量的物件，而大量的這些物件造成了很大的儲存開銷時應該考慮使用。物件的大多數狀態可以是外部狀態，如果刪除物件的外部狀態，那麼可以用相對較少的共享物件取代很多組物件，此時也可以考慮用享元模式。享元模式uml圖如下 如下 使用者 cl...
設計模式之享元模式
場景 記憶體屬於稀缺資源，不要隨便浪費。如果有很多個完全相同或相似的物件，我們可以通過享元模式，節省記憶體 核心 享元物件能夠做到共享的關鍵是區分了內部狀態和外部狀態 內部狀態 可以共享，不會隨環境變化而改變 外部狀態 不可以共享，會隨環境的變化而改變 簡單享元結構 復合享元模式的結構 統比一下單純...