簡說設計模式享元模式

說到享元模式，第乙個想到的應該就是池技術了，string常量池、資料庫連線池、緩衝池等等都是享元模式的應用，所以說享元模式是池技術的重要實現方式。

比如我們每次建立字串物件時，都需要建立乙個新的字串物件的話，記憶體開銷會很大，所以如果第一次建立了字串物件「adam「，下次再建立相同的字串」adam「時，只是把它的引用指向」adam「，這樣就實現了」adam「字串再記憶體中的共享。

舉個最簡單的例子，網路聯機下棋的時候，一台伺服器連線了多個客戶端（玩家），如果我們每個棋子都要建立物件，那一盤棋可能就有上百個物件產生，玩家多點的話，因為記憶體空間有限，一台伺服器就難以支援了，所以這裡要使用享元模式，將棋子物件減少到幾個例項。下面給出享元模式的定義。

享元模式（flyweight），運用共享技術有效地支援大量細粒度的物件。uml結構圖如下：

所有具體享元類的超類或介面，通過這個介面，flyweight可以接受並作用於外部狀態。

1
public
abstract
class
flyweight 
1213
//定義業務操作
14public
abstract
void operate(int
extrinsic);
1516
public
string getintrinsic() 
1920
public
void
setintrinsic(string intrinsic) 
2324 }

繼承flyweight超類或實現flyweight介面，並為其內部狀態增加儲存空間。

1
public
class concreteflyweight extends
flyweight 78
//根據外部狀態進行邏輯處理
9@override
10public
void operate(int
extrinsic) 
1314 }

指那些不需要共享的flyweight子類。

1
public
class unsharedconcreteflyweight extends
flyweight 67
@override
8public
void operate(int
extrinsic) 
1112 }

乙個享元工廠，用來建立並管理flyweight物件，主要是用來確保合理地共享flyweight，當使用者請求乙個flyweight時，flyweightfactory物件提供乙個已建立的例項或建立乙個例項。

1
public
class
flyweightfactory else
2021
return
flyweight;22}
23 }

1
public
class
client 
2122 }

執行結果如下：

從這個結果我們可以看出來，第一次建立x、y、z時，都是先建立再從池中取出，而第二次建立x時，因為池中已經存在了，所以直接從池中取出，這就是享元模式。

上面享元模式的定義為我們提出了兩個要求：細粒度和共享物件。我們知道分配太多的物件到應用程式中將有損程式的效能，同時還容易造成記憶體溢位，要避免這種情況，用到的就是共享技術，這裡就需要提到內部狀態和外部狀態了。

因為要求細粒度物件，所以不可避免地會使物件數量多且性質相近，此時我們就將這些物件的資訊分為兩個部分：內部狀態和外部狀態。

內部狀態指物件共享出來的資訊，儲存在享元物件內部並且不會隨環境的改變而改變；外部狀態指物件得以依賴的乙個標記，是隨環境改變而改變的、不可共享的狀態。

我們舉乙個最簡單的例子，棋牌類遊戲大家都有玩過吧，比如說說圍棋和跳棋，它們都有大量的棋子物件，圍棋和五子棋只有黑白兩色，跳棋顏色略多一點，但也是不太變化的，所以棋子顏色就是棋子的內部狀態；而各個棋子之間的差別就是位置的不同，我們落子嘛，落子顏色是定的，但位置是變化的，所以方位座標就是棋子的外部狀態。

那麼為什麼這裡要用享元模式呢？可以想象一下，上面提到的棋類遊戲的例子，比如圍棋，理論上有361個空位可以放棋子，常規情況下每盤棋都有可能有兩三百個棋子物件產生，因為記憶體空間有限，一台伺服器很難支援更多的玩家玩圍棋遊戲，如果用享元模式來處理棋子，那麼棋子物件就可以減少到只有兩個例項，這樣就很好的解決了物件的開銷問題。

應用例項的話，其實上面的模板就已經是乙個很好的例子了，類似於string常量池，沒有的物件建立後存在池中，若池中存在該物件則直接從池中取出。

為了更好的理解享元模式，這裡再舉乙個例項，比如接了我乙個小型的外包專案，是做乙個產品展示**，後來他的朋友們也希望做這樣的**，但要求都有些不同，我們當然不能直接複製貼上再來乙份，有任希望是新聞發布形式的，有人希望是部落格形式的等等，而且因為經費原因不能每個**租用乙個空間。

其實這裡他們需要的**結構相似度很高，而且都不是高訪問量**，如果分成多個虛擬空間來處理，相當於乙個相同**的例項物件很多，這是造成伺服器的大量資源浪費。如果整合到乙個**中，共享其相關的**和資料，那麼對於硬碟、記憶體、cpu、資料庫空間等伺服器資源都可以達成共享，減少伺服器資源；而對於**，由於是乙份例項，維護和擴充套件都更加容易。

那麼此時就可以用到享元模式了。uml圖如下：

這裡使用hashmap來作為池，通過put和get方法實現加入池與從池中取的操作。

1
public
class
websitefactory 
1011
return
(website)pool.get(key);12}
1314
//獲得**分類總數
15public
intgetwebsitecount() 
1819 }

這裡測試用例給了兩種**，原先我們需要做三個產品展示和三個部落格的**，也即需要六個**類的例項，但其實它們本質上都是一樣的**，可以利用使用者id號的不同，來區分不同的使用者，具體資料和模板可以不同，但**核心和資料庫卻是共享的。

1
public
class
client 
2627 }

執行結果如下：

可以看出，雖然我們做了6個**，但**分類只有2個。這樣基本算是實現了享元模式的共享物件的目的，但想想上面提到的內部狀態和外部狀態，這裡實際上沒有體現物件間的不同，只體現了它們的共享部分。

下面新增乙個user類。

1
public
class
user 89
public
string getname() 
1213 }

然後再對use()方法進行修改，新增引數，以抽象類為例： public

abstract

void use(user user);

而客戶端中只需對每乙個**新增乙個使用者即可，如： fx.use(new user("adam"));

執行結果如下：

這樣就可以協調內部與外部狀態，哪怕接手了上千個**的需求，只要要求相同或類似，實際開發**也就是分類的哪幾種。

簡說設計模式 享元模式

設計模式（享元模式）

設計模式 享元模式

設計模式 享元模式

相關推薦

簡說設計模式享元模式

設計模式享元模式

設計模式享元模式