今天差點就不想堅持學習了，不過 還是 覺得 要堅持。 明天後天更要堅持。。 加油！
享元模式以共享的方式高效的支援大量的細粒度物件。享元物件能做到共享的關鍵是區分內蘊狀態（internal state）和外蘊狀態（external state）。內蘊狀態是儲存在享元物件內部並且不會隨著環境改變而改變。因此內蘊狀態才可以共享。
外蘊狀態是隨著環境改變而改變的，不可以共享的狀態。享元物件的外蘊狀態必須由客戶端儲存，並在享元物件被建立之後，在需要使用的時候再傳入到享元物件內部。外蘊狀態與內蘊狀態是相互獨立的。
享元模式結構：
抽象享元角色（flyweght）：：此角色是所有的具體享元類的超類，為這規定出需要實現的公共介面。那些需要外蘊狀態(external state)的操作可以通過呼叫商業方法以引數形式傳入。
具體享元角色（concreteflyweight）：實現抽象享元角色所規定的介面。如果有內蘊狀態的話，必須負責為內蘊狀態提供儲存空間。享元物件的內蘊狀態必須與物件所處的周圍環境無關，從而使得享元物件可以在系統內共享的。
享元工廠角色（flyweightfactory）：本角色負責建立和管理享元角色。本角色必須保證享元物件可以被系統適當地共享。當乙個客戶端物件呼叫乙個享元物件的時候，享元工廠角色會檢查系統中是否已經有乙個復合要求的享元物件。如果已經有了，享元工廠角色就應當提供這個已有的享元物件；如果系統中沒有乙個適當的享元物件的話，享元工廠角色就應當建立乙個合適的享元物件。
客戶端角色（client）：本角色需要維護乙個對所有享元物件的引用。本角色需要自行儲存所有享元物件的外蘊狀態。
復合享元模式的結構：
單純享元模式中，所有的享元物件都可以直接共享。
說明：
享元模式應當在什麼情況下使用 ：
1.乙個系統有大量的物件。
2.這些物件耗費大量的記憶體。
3.這些物件的狀態中的大部分都可以外部化。
4.這些物件可以按照內蘊狀態分成很多的組，當把外蘊物件從物件中剔除時，每乙個組都可以僅用乙個物件代替。
5.軟體系統不依賴於這些物件的身份，換言之，這些物件可以是不可分辨的。
最後，享元模式需要維護乙個記錄了系統已有的所有享元的表，而這需要耗費資源。因此，應當在有足夠多的享元例項可供共享時才值得使用享元模式。
享元模式的優點和缺點：
1.享元模式使得系統更加複雜。為了使物件可以共享，需要將一些狀態外部化，這使得程式的邏輯複雜化。
2.享元模式將享元物件的狀態外部化，而讀取外部狀態使得執行時間稍微變長。
總結：總原理上來看 這個享元模式 好像有點像單例模式，都是將乙個例項化的新物件儲存到乙個容器中，當下次需要使用的時候 可以直接拿去使用，而不需要從新例項化，然而不同的地方在於，在裡可以根據環境的變化，例項化多個不同的物件統一放到乙個集合中，當要使用的時候可以在集合中尋找現有的物件。從而達到了乙個共享的作用。好像在開發過程中沒怎麼遇到過這總需求哈，除非很多類 都很常用，並且這些類裡面 都不包含業務屬性。 要不然 如果公用的話業務就串了。。
設計模式（享元模式）
享元模式是設計模式中少數幾個已提高系統效能為目的模式之一。它的核心思想是 如果系統存在多個 相同的物件，那麼只需要共享一分物件的拷貝，而不必為每一次使用都建立新的物件。當有物件被大量復用時，特別是重量級的物件復用可以使用享元模式來提高系統效能。其優點如下 1.可以節省重複建立物件的開銷，因為被享元模...
設計模式 享元模式
享元模式flyweight flyweight 模式是乙個提高程式效率和效能的模式 會大大加快程式的執行速度。把物件中使用比較多，具有共同點的，拿出來做成乙個共享類，這樣就行成了共享模式。如 integer 物件在 128 127 使用的是同乙個物件。在這之間是共享的。享元中的角色 flyweigh...
設計模式 享元模式
舉個圍棋的例子，圍棋的棋盤共有361格，即可放361個棋子。現在要實現乙個圍棋程式，該怎麼辦呢？首先要考慮的是棋子棋盤的實現，可以定義乙個棋子的類，成員變數包括棋子的顏色 形狀 位置等資訊，另外再定義乙個棋盤的類，成員變數中有個容器，用於存放棋子的物件。下面給出 表示 棋子的定義，當然棋子的屬性除了...