享元模式不同于一般的設計模式，它主要用來優(yōu)化程序的性能，它最適合解決大量類似的對象而產生的性能問題。享元模式通過分析應用程序的對象，將其解析為內在數(shù)據和外在數(shù)據，減少對象的數(shù)量，從而提高應用程序的性能。

基本知識

享元模式通過共享大量的細粒度的對象，減少對象的數(shù)量，從而減少對象的內存，提高應用程序的性能。其基本思想就是分解現(xiàn)有類似對象的組成，將其展開為可以共享的內在數(shù)據和不可共享的外在數(shù)據，我們稱內在數(shù)據的對象為享元對象。通常還需要一個工廠類來維護內在數(shù)據。

在JS中，享元模式主要有下面幾個角色組成：

（1）客戶端：用來調用享元工廠來獲取內在數(shù)據的類，通常是應用程序所需的對象，

（2）享元工廠：用來維護享元數(shù)據的類

（3）享元類：保持內在數(shù)據的類

享元模式的實現(xiàn)和應用

一般實現(xiàn)

我們舉個例子進行說明：蘋果公司批量生產iphone，iphone的大部分數(shù)據比如型號，屏幕都是一樣，少數(shù)部分數(shù)據比如內存有分16G,32G等。未使用享元模式前，我們寫代碼如下：

function Iphone(model, screen, memory, SN) {

  this. model = model;

  this.screen = screen;

  this.memory = memory;

  this.SN = SN;

}

var phones = [];

for (var i = 0; i < 1000000; i++) {

  var memory = i % 2 == 0 ? 16 : 32;

  phones.push(new Iphone("iphone6s", 5.0, memory, i));

}

這段代碼中，創(chuàng)建了一百萬個iphone，每個iphone都獨立申請一個內存。但是我們仔細觀察可以看到，大部分iphone都是類似的，只是內存和序列號不一樣，如果是一個對性能要求比較高的程序，我們就要考慮去優(yōu)化它。

大量相似對象的程序，我們就可以考慮用享元模式去優(yōu)化它，我們分析出大部分的iphone的型號，屏幕，內存都是一樣的，那這部分數(shù)據就可以公用，就是享元模式中的內在數(shù)據，定義享元類如下：

function IphoneFlyweight(model, screen, memory) {

  this.model = model;

  this.screen = screen;

  this.memory = memory;

}

我們定義了iphone的享元類，其中包含型號，屏幕和內存三個數(shù)據。我們還需要一個享元工廠來維護這些數(shù)據：

var flyweightFactory = (function () {

  var iphones = {};

  return {

    get: function (model, screen, memory) {

      var key = model + screen + memory;

      if (!iphones[key]) {

        iphones[key] = new IphoneFlyweight(model, screen, memory);

      }

      return iphones[key];

    }

  };

})();

在這個工廠中，我們定義了一個字典來保存享元對象，提供一個方法根據參數(shù)來獲取享元對象，如果字典中有則直接返回，沒有則創(chuàng)建一個返回。

接著我們創(chuàng)建一個客戶端類，這個客戶端類就是修改自iphone類：

function Iphone(model, screen, memory, SN) {

  this.flyweight = flyweightFactory.get(model, screen, memory);

  this.SN = SN;

}

然后我們依舊像之間那樣生成多個iphone

var phones = [];

for (var i = 0; i < 1000000; i++) {

  var memory = i % 2 == 0 ? 16 : 32;

  phones.push(new Iphone("iphone6s", 5.0, memory, i));

}

console.log(phones);

這里的關鍵就在于Iphone構造函數(shù)里面的this.flyweight = flyweightFactory.get(model, screen, memory)。這句代碼通過享元工廠去獲取享元數(shù)據，而在享元工廠里面，如果已經存在相同數(shù)據的對象則會直接返回對象，多個iphone對象共享這部分相同的數(shù)據，所以原本類似的數(shù)據已經大大減少，減少的內存的占用。

享元模式在DOM中的應用

享元模式的一個典型應用就是DOM事件操作，DOM事件機制分成事件冒泡和事件捕獲。我們簡單介紹一下這兩者：

事件冒泡：綁定的事件從最里層的元素開始觸發(fā)，然后冒泡到最外層

事件捕獲：綁定的事件從最外層的元素開始觸發(fā)，然后傳到最里層

假設我們HTML中有一個菜單列表

<ul class="menu">

  <li class="item">選項1</li>

  <li class="item">選項2</li>

  <li class="item">選項3</li>

  <li class="item">選項4</li>

  <li class="item">選項5</li>

  <li class="item">選項6</li>

</ul>

點擊菜單項，進行相應的操作，我們通過jQuery來綁定事件，一般會這么做：

$(".item").on("click", function () {

  console.log($(this).text());

})

給每個列表項綁定事件，點擊輸出相應的文本。這樣看暫時沒有什么問題，但是如果是一個很長的列表，尤其是在移動端特別長的列表時，就會有性能問題，因為每個項都綁定了事件，都占用了內存。但是這些事件處理程序其實都是很類似的，我們就要對其優(yōu)化。

$(".menu").on("click", ".item", function () {

  console.log($(this).text());

})

通過這種方式進行事件綁定，可以減少事件處理程序的數(shù)量，這種方式叫做事件委托，也是運用了享元模式的原理。事件處理程序是公用的內在部分，每個菜單項各自的文本就是外在部分。我們簡單說下事件委托的原理：點擊菜單項，事件會從li元素冒泡到ul元素，我們綁定事件到ul上，實際上就綁定了一個事件，然后通過事件參數(shù)event里面的target來判斷點擊的具體是哪一個元素，比如低級第一個li元素，event.target就是li，這樣就能拿到具體的點擊元素了，就可以根據不同元素進行不同的處理。

總結

享元模式是一種優(yōu)化程序性能的手段，通過共享公用數(shù)據來減少對象數(shù)量以達到優(yōu)化程序的手段。享元模式適用于擁有大量類似對象并且對性能有要求的場景。因為享元模式需要分離內部和外部數(shù)據，增加了程序的邏輯復雜性，建議對性能有要求的時候才使用享元模式。

享元模式之利：

可以把網頁的資源符合降低幾個數(shù)量級。即使享元模式的應用無法將實例的個數(shù)削減到一個，你仍能夠從中獲益不少。

這種節(jié)省不需要大量修改原有代碼。在創(chuàng)建了管理器、工廠和享元之后，就需要對代碼進行的修改只不過是從直接實例化目標類改為調用管理器對象的某個方法。

享元模式之弊：

如果把它用在不必要的地方，其結果反而有損代碼的運行效率。這種模式在優(yōu)化代碼的同時，也提高了其復雜程度，這會給調試和維護造成困難。

它之所以會妨礙調試，是因為現(xiàn)在可能出錯的地方變成了三個：管理器、工廠和享元。

這種優(yōu)化也會使維護變得更加困難。現(xiàn)在你面對的不是由封裝著數(shù)據的對象構成的清晰架構，而是一堆又碎又亂的東西。其中的數(shù)據至少分兩處保存。最好注釋標明內在數(shù)據和外在數(shù)據。

只有在必要的時候才應該進行這種優(yōu)化。必須在運行效率和可維護性之間進行權衡。如果拿不準是否需要使用享元模式，那么你很可能并不需要它。享元模式適合的是系統(tǒng)資源已經用得差不多而且明顯需要進行某種優(yōu)化這樣一類場合。

這種模式對Javascript程序員特別有用，因為它可以用來減少網頁上所要使用的DOM元素的數(shù)量，要知道這些元素需要耗費許多內存。結合使用這種模式與組合模式等組織型可以開發(fā)出功能豐富的復雜Web應用系統(tǒng)，它們可以平穩(wěn)的運行在任何現(xiàn)代Javascript環(huán)境中。

享元模式的適用場合：

網頁中必須使用了大量資源密集型對象。如果只會用到少許這類對象，這種優(yōu)化并不劃算。

對象中所保存的數(shù)據至少有一部分能被轉化為外在數(shù)據。此外，將這些數(shù)據存儲在對象外部所占用的資源應該相對較少，否則這種做法對于性能的提示實際上毫無意義。那種大量包含基礎性代碼和HTML內容的對象可能比較適合這種優(yōu)化。

將外在數(shù)據分離出去后，獨一無二的對象的數(shù)目相對較少。