本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7792973.html，記錄一下學習程序以備后續查用，
一、引言
今天我們要講結構型設計模式的第六個模式--享元模式，先從名字上來看，“享元”可以這樣理解--共享“單元”，單元是什么呢？舉例說明：對于圖形而言就
是圖元；對于英文來說就只26個英文字母；對于漢語來說就是每個漢字，也可以這樣理解“元”--構成事物的最小單元，這些單元如果大量且重復出現，我們可
以快取重復出現的單元，達到節省記憶體的目的，換個說法享元是為了節省空間，對于計算機而言就是節省記憶體，
面向物件很好地解決了系統抽象性的問題（系統抽象性指把系統里面的事物寫成類，類可以實體化成為物件，用物件和物件之間的關系來設計系統），在
大多數情況下，這樣做是不會損及系統的性能的，但是，在某些特殊的應用中，由于物件的數量太大，并且這些大量的物件中有很多是重復的，如果每個對
象都單獨的創建（C#的語法是new）出來，會給系統帶來難以承受的記憶體開銷，比如圖形應用中的圖元等物件、字處理應用中的字符物件等，
二、享元模式介紹
享元模式：英文名稱--Flyweight Pattern；分類--結構型，
2.1、動機（Motivate）
在軟體系統中，采用純粹物件方案的問題在于大量細粒度的物件會很快充斥在系統中，從而帶來很高的運行時代價--主要指記憶體需求方面的代價，如何在避
免大量細粒度物件問題的同時，讓外部客戶程式仍然能夠透明地使用面向物件的方式來進行操作？
2.2、意圖（Intent）
運用共享技術有效地支持大量細粒度的物件，——《設計模式》GoF
2.3、結構圖（Structure）
2.4、模式的組成
1）抽象享元角色（Flyweight）：此角色是所有的具體享元類的基類，為這些類規定出需要實作的公共介面，那些需要外部狀態的操作可以通過呼叫方法
以引數形式傳入，
2）具體享元角色（ConcreteFlyweight）：實作抽象享元角色所規定的介面，如果有內部狀態的話，可以在類內部定義，
3）享元工廠角色（FlyweightFactory）：本角色負責創建和管理享元角色，本角色必須保證享元物件可以被系統適當地共享，當一個客戶端物件呼叫一個
享元物件的時候，享元工廠角色檢查系統中是否已經有一個符合要求的享元物件，如果已經存在，享元工廠角色就提供已存在的享元物件，如果系統中沒有
一個符合的享元物件的話，享元工廠角色就應當創建一個合適的享元物件，
4）客戶端角色（Client）：本角色需要存盤所有享元物件的外部狀態，
2.5、享元模式的具體代碼實作
說起“享元模式”，我這里有一個很好的場景可以進行說明，我們知道在戰斗的游戲場景中，會有很多戰士，基本上戰士都是差不多的，最大的區別就是拿的
武器不同而已，在大型的戰爭游戲中，會有大量的士兵出來戰斗，我們寫程式的時候就可以用“享元”來解決大量戰士的情況，
class Program { /// <summary> /// 這些是輔助型別 /// </summary> public enum SoldierType { Normal, Water } /// <summary> /// 該型別就是抽象戰士Soldier--該型別相當于抽象享元角色 /// </summary> public abstract class Soldier { //通過建構式初始化士兵的名稱 protected Soldier(string name) { Name = name; } //士兵的名字 public string Name { get; private set; } //傳入不同的武器就用不同的活力--該方法相當于抽象Flyweight的Operation方法 public abstract void Fight(); public Weapen WeapenInstance { get; set; } } /// <summary> /// 一般型別的戰士，武器是步槍--相當于具體的Flyweight角色 /// </summary> public sealed class NormalSoldier : Soldier { //通過建構式初始化士兵的名稱 public NormalSoldier(string name) : base(name) { } //執行享元的方法--就是Flyweight型別的Operation方法 public override void Fight() { WeapenInstance.Fire("士兵：" + Name + "在陸地執行擊斃任務，"); } } /// <summary> /// 這是海軍陸戰隊隊員，武器精良--相當于具體的Flyweight角色 /// </summary> public sealed class WaterSoldier : Soldier { //通過建構式初始化士兵的名稱 public WaterSoldier(string name) : base(name) { } //執行享元的方法--就是Flyweight型別的Operation方法 public override void Fight() { WeapenInstance.Fire("士兵：" + Name + "在海中執行擊斃任務，"); } } /// <summary> /// 此型別和享元沒太大關系，可以算是享元物件的狀態吧，需要從外部定義， /// </summary> public abstract class Weapen { public abstract void Fire(string jobName); } /// <summary> /// 此型別和享元沒太大關系，可以算是享元物件的狀態吧，需要從外部定義， /// </summary> public sealed class AK47 : Weapen { public override void Fire(string jobName) { Console.WriteLine(jobName); } } /// <summary> /// 該型別相當于是享元的工廠--相當于FlyweightFactory型別 /// </summary> public sealed class SoldierFactory { private static IList<Soldier> soldiers; static SoldierFactory() { soldiers = new List<Soldier>(); } Soldier mySoldier = null; //因為我這里有兩種士兵，所以在這里可以增加另外一個引數--士兵型別，原模式里面沒有， public Soldier GetSoldier(string name, Weapen weapen, SoldierType soldierType) { foreach (Soldier soldier in soldiers) { if (string.Compare(soldier.Name, name, true) == 0) { mySoldier = soldier; return mySoldier; } } //我們這里就任務名稱是唯一的 if (soldierType == SoldierType.Normal) { mySoldier = new NormalSoldier(name); } else { mySoldier = new WaterSoldier(name); } mySoldier.WeapenInstance = weapen; soldiers.Add(mySoldier); return mySoldier; } } static void Main(string[] args) { #region 享元模式 //比如，我們現在需要100個一般士兵， SoldierFactory factory = new SoldierFactory(); AK47 ak47 = new AK47(); for (int i = 0; i < 100; i++) { Soldier soldier = null; if (i <= 20) { soldier = factory.GetSoldier("士兵" + (i + 1), ak47, SoldierType.Normal); } else { soldier = factory.GetSoldier("士兵" + (i + 1), ak47, SoldierType.Water); } soldier.Fight(); } //我們有這么多的士兵，但是使用的記憶體不是很多，因為我們快取了， Console.Read(); #endregion } }View Code
運行結果如下：
這個模式很簡單，就話不多說了，
三、享元模式的實作要點
面向物件很好地解決了抽象性的問題，但是作為一個運行在機器中的程式物體，我們需要考慮物件的代價問題，Flyweight設計模式主要解決面向物件的代
價問題，一般不觸及面向物件的抽象性問題，
Flyweight采用物件共享的做法來降低系統中物件的個數，從而降低細粒度物件給系統帶來的記憶體壓力，在具體實作方面，要注意物件狀態的處理，物件的
數量太大從而導致物件記憶體開銷加大--什么樣的數量才算大？這需要我們仔細的根據具體應用情況進行評估，而不能憑空臆斷，
3.1、享元模式的優點
1）享元模式的優點在于它能夠極大的減少系統中物件的個數，
2）享元模式由于使用了外部狀態，而外部狀態相對獨立，不會影響到內部狀態，所以享元模式使得享元物件能夠在不同的環境被共享，
3.2、享元模式的缺點
1）由于享元模式需要區分外部狀態和內部狀態，使得應用程式在某種程度上來說更加復雜化了，
2）為了使物件可以共享，享元模式需要將享元物件的狀態外部化，而讀取外部狀態使得運行時間變長，
3.3、在下面所有條件都滿足時，可以考慮使用享元模式：
1）一個系統中有大量的物件，
2）這些物件耗費大量的記憶體，
3）這些物件中的狀態大部分都可以被外部化，
4）這些物件可以按照內部狀態分成很多的組，當把外部物件從物件中剔除時，每一個組都可以僅用一個物件代替軟體系統不依賴這些物件的身份，
滿足上面的條件的系統可以使用享元模式，但是使用享元模式需要額外維護一個記錄子系統已有的所有享元的表，而這也需要耗費資源，所以，應當在有足
夠多的享元實體可共享時才值得使用享元模式，
四、.NET 中享元模式的實作
.NET在C#中有一個Code Behind機制，它表面有一個aspx檔案，背后又有一個cs檔案，它的編譯程序實際上會把aspx檔案決議成C#檔案，然后編譯成dll，
在這個程序中，我們在aspx中寫的任何html代碼都會轉化為literal control，literal control是一個一般的文本控制元件，它就表示html標記，當這些標記有相同的時候，
構建控制元件樹時就會用到Flyweight模式，它的應用并不是那么頻繁，只有在效率空間確實不高的時候我們才用它，
五、總結
剛開始接觸這個模式的時候，感覺這個模式不是特別難，在我們編碼的程序中也有涉及，但是在學習的程序中也走了不少彎路，任何設計模式都有他特定的
使用場景，小心誤用，這個模式在業務系統中相對而言使用的并不多，在類似游戲場景中、字符處理等系統用的比較多，還是老話，通過迭代來使用模式，別
為了模式而模式，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/71323.html
標籤：C#
上一篇：c#報表列印