Flyweight享元模式（結構型模式）

意圖（intention）

結構（structure）

兩個狀態

flyweight模式的幾個要點

適用場景

example

運用共享技術有效地支援大量細粒度的物件。

其中，flyweight抽象享元物件：為具體享元角色規定了必須實現的方法，而外部狀態是以引數的形式傳入此方法。

concreteflyweight具體享元角色：實現抽象享元角色規定的方法。如果存在內蘊狀態，就負責為內蘊狀態提供儲存空間。

unsharedconcreteflyweight非共享具體享元角色：並非所有的flyweight子類都需要被共享。flyweight介面使共享變成可能，但是它並不強制共享。

flyweightfactory享元工廠角色：負責建立和管理享元角色，提供乙個已經建立的例項或者不存在時建立乙個例項。

clint客戶端角色：維護對所有享元物件的引用，而且還需要儲存對應的外蘊狀態。

內蘊狀態/內部狀態：儲存在享元內部，不隨環境改變而有所不不同，可共享。

外蘊狀態/外部狀態：不可共享，隨環境改變而改變，由客戶端來維持。

1.物件導向很好地解決了抽象性的問題，但是作為乙個執行在機器中的程式實體，我們需要考慮物件的代價問題。flayweight設計模式主要解決物件導向的代價問題，一般不觸及物件導向的抽象性問題。

2.flyweight採用物件共享的做法來降低系統中物件的個數，從而降低細粒度物件給系統帶來的記憶體壓力。在具體實現方面，要注意物件狀態的處理。

3.物件的數量太大從而導致物件記憶體開銷加大--什麼樣的數量才算大？這需要我們仔細的根據具體應用情況進行評估，而不能憑空臆斷。

1.乙個應用程式使用了大量的物件。

2.完全由於使用大量的物件，造成很大的儲存開銷。

3.物件的大多數狀態都可以變為外部狀態。

4.如果刪除物件的外部狀態，那麼可以用相對較少的共享物件取代很多組物件。

一句話來說，就是如果乙個應用程式使用了大量的物件，而這些物件造成了很大的儲存開銷的時候就可以考慮是否可以使用享元模式。

背景：需要做3個產品展示**，3個部落格**，這就需要6個**類的例項，如果每乙個都需要乙個例項的話，隨著**的增多，例項數量也就增多，對伺服器資源浪費就很嚴重。這就需要用到享元模式來解決這個問題了。其實，3個產品展示**只需要例項化1個就可以，3個部落格**也只需要例項化出1個，然後根據不同的使用者id來進行區分（外蘊狀態），核心**和資料庫共享。

**實現

abstract class website

class concretewebsite : website
//實現user方法
public override void use(user user)
}

**工廠類：對應於結構圖中的 flyweightfactory享元工廠角色，在建立不同種類的**時，先判斷該**例項是否存在，如果存在，直接返回，若不存在，先例項化乙個再返回

class websitefactory
return ((website)flyweights[key]);}}

客戶端**：建立了小王的產品展示**，小李的產品展示**，小王的部落格**，小李的部落格**，但是實際上產品展示**和部落格**只例項化了一次，其中外部狀態使用者id是通過user user這個引數傳入的。

websitefactory f = new websitefactory();
//例項化「產品展示**」物件
website fx = f.getwebsitecategory("產品展示");
fx.use(new user("小王"));
//共享上方生成的「產品展示**」物件，不再例項化
website fy = f.getwebsitecategory("產品展示");
fy.use(new user("小李"));
//例項化「部落格」的「**」物件
website fl = f.getwebsitecategory("部落格");
fl.use(new user("小王"));
//共享上方生成的「部落格**」物件，不再例項化
website fm = f.getwebsitecategory("部落格");
fm.use(new user("小李"));

執行結果如下

Flyweight享元模式（結構型模式）

享元模式（Flyweight）結構型

FlyWeight 享元模式

享元模式 Flyweight

Flyweight享元模式（結構型模式）

享元模式（Flyweight） 結構型

FlyWeight 享元模式

享元模式 Flyweight

相關推薦

享元模式（Flyweight）結構型