Javascript 部分設計模式的我的理解

9 單例模式（確保本身使用的資源都是全局的）

1）普通單體（字面量初始化對象）

var person = {
name : 'zhangsan',
age : 12,
getAge : function(){
return this.age ;
}
}
person.height = 185 ;

這種單體在實際開發中經常使用在兩個地方，其一就是 匿名對象，其二就是 劃分命名空間！

2 )具備局部變量的單體（動態加載數據，初始化屬性，返回一個對象實例）

 var UserInfo = (function(){           //同閉包的原
  var name = "";         //利用閉包是單體有本身的私有局部變量
  var code = "";
  Ajax.request("url",function(n,c){
   name = n;
   code = c;
  })
  return {
   name:name,
   code:code
  }
 })()

3）惰性單體（用一個私有變量代替第二種方法返回的實例）

var UserInfo = (function(){
  var userInfo = "";      //私有變量
  function init(){        //利用閉包是單體有本身的私有局部變量 
   var name = "";
   var code = "";
   Ajax.request("url",function(n,c){ 
    name = n;
    code = c;
   })
   return {
    name:name,
    code:code
 } 
  }
  return {
   getInstance : function(){
    if(userInfo){
     return userInfo;
    }else{
     userInfo = init();
     return userInfo;
    }
   }
  }
 })()

4 ) 分支單體（這種方法就是經過判斷返回一個什麼樣的實例，也就是分支，是上面方法的結合使用）

10 工廠模式

1）簡單工廠（簡單的說就是一個接口以及他的多個實現類，經過一個單例工廠類來根據客戶的需求new 出對應接口實現類的對象，這種方式其實就是相似於java裏面的靜態工廠模式，沒有多大意義。緣由就是沒有動態效果，若是新增一個實現類又要改變if語句，又要修改工廠類的源碼，沒意義！）

2）工廠模式（他與工廠模式的區別就在於它是給人誤解爲動態的，他的整個個原理是這樣的：在簡單工廠模式的基礎下，把工廠類定義爲抽象類，那麼具體工廠類的實現類就是咱們經過使用if語句來判斷new出什麼對象的一個類，那麼它會根據不一樣的狀況有各類各樣的工廠實現類，那麼接口有新的實現類時不必改變全部的工廠實現類，只需改變其中須要的那個就能夠了，因此這也不是動態的）

11 橋樑模式

    1）目的：將抽象類與其實現類隔離開來，以便兩者獨立開來，互不干擾的開發！

    2）思想：好比咱們任意寫一個了服務類，不少客戶端都要調用這個類的服務，那麼我就能夠在客戶端與服務類之間新建一個橋樑，用來處理兩者的相互調用，這樣就能把兩者分離開來！固然這個確實有點相似於門面模式或適配器模式，然而意義是不同的。

        A 對於適配器模式來講：他的目的是在服務類並不能直接被客戶端所用（不兼容）的狀況下，要在中間設置一個適配器來改造服務類的調用，但又不修改服務類自己。

        B 對於橋樑模式來講：他的目的是在客戶端調用服務類時，用一個橋樑把兩者隔離開來，從而達到兩者互不干擾的目的。並且橋樑模式還有一個很重要的做用就是在橋樑中可以處理多個不一樣服務類的之間的相互調用！

        C 對於門面模式來講：他的目的是爲服務類建立一箇中間便利類，把複雜接口改形成一個簡單易用的接口，他與以上兩種設計模式的差別就在於門面模式並非強調服務類被某個或某些特定的客戶端容易調用，而是爲服務類編寫一個容易被調用的接口門面類。因此，對於瀏覽器不兼容的服務類咱們就應該使用門面模式來封裝，好比事件註冊，XMLHttpRequest封裝

12 門面模式

    1）做用：簡化類的接口，同時消除服務類與使用它的客戶端之間的耦合，還可以完成與與橋接模式相似的功能就是多個類的相互調用在門面類中。

    2）思想：好比咱們寫了一個服務類，他的接口很複雜，然而咱們就能夠爲這個服務類建立一個門面類，這個門面類的目的就是爲了簡化服務類接口的調用。這裏徹底沒有牽連到客戶端的東西，緣由就是門面模式是爲服務類服務的，適配器模式是爲了服務類與客戶端兼容的，橋樑模式是爲了服務類與客戶類分離的。

    3）所謂的一些封裝或者腳本庫如Jquery等都是採用門面模式的原理。

13 適配器模式

    1）概念：適配器模式可用來在現有接口和不兼容的類之間進行適配，其實也就是包裝模式，由於是在用一個新的接口包裝成另外一個對象，許多狀況下，許多服務類接口並不能直接被客戶端所使用，這時咱們藉助於適配器模式，你不用直接修改這些服務類，而是藉助一個適配器來改造他的接口，從而達到客戶端的可調用性。

    2）適配器模式很想買門面模式，他們都要對別的對象進行包裝並改變其呈現的接口，兩者的差別在於：他們是如何改變接口的，門面模式展示的是一個簡化的接口，他並不提供額外的選擇，並且有時爲了方便完成常見的任務他還會作出一些假設。適配器則要把一個接口轉換爲另外一個接口，他並不會濾除某些能力，也不會簡化接口，若是客戶系統期待的API不可用，那就須要用到適配器。

14 組合模式

    1）一種專爲建立Web上的動態用戶界面而量身定製模式，使用這種模式，能夠用一條命令在多個對象上激發複雜的或遞歸的行爲。

    2）思想：就是相似於文件夾，一個組合類中有組合類同時還會有葉子類，這種模式我我的以爲用在的場合和特殊，只能是這種包含於被包含並且是在葉子節點和組合節點有相同特徵的狀況下使用。因此咱們的組合類和葉子類都必須實現相同的接口，並且組合類中應該保存葉子類的引用和組合類的引用。

15 裝飾模式

    1）概念：可用來透明的把對象包裝在具備一樣接口的另外一對象之中，經過在另外一個對象中添加對應的實現功能完成原始對象的裝飾。目的就是減小子類。

    2）思想：對於一個服務類，須要在這個服務類的某個接口上新增一些功能，並且服務類是不能修改的，那麼咱們可能會選擇新建一個子類來重寫這個方法，這樣固然能夠實現，可是若是對每添加一個功能都要建立一個新類的話，會產生大量的子類，因此就有裝飾模式，裝飾類與服務類實現同一個接口，並且裝飾類裏面具備服務類的引用，所謂裝飾就是在裝飾類重寫方法的時候調用了服務類的同名方法，於此同時還添加了本身的功能。

    3）對比：代理模式也是在爲服務類的某個接口改變一些功能，注意是改變不必定就是新增功能，因此這就是代理模式的本質區別，裝飾模式是說在調用服務類的方法同時可以新增一些功能，那麼在裝飾模式中服務類的接口是必定會被調用的，然而代理模式則不是，使不使用服務類的接口那是代理類自己來決定的。可是代理模式和裝飾模式的實現幾乎相同，由於代理模式也是這樣實現的，代理類與被代理類都實現了相同的接口，同時代理類中有被代理類的引用。

    4）對比：裝飾模式和組合模式之間有許多共同點，裝飾者對象和組合對象都是用來包裝別的對象，他們都與所包裝的對象實現一樣的接口而且會把任何方法調用傳遞給這些對象。組合模式是一種結構模式，用於把衆多子對象組織爲一個總體，當程序員與大批對象打交道時能夠將他們當作一個對象來對待，並將他們組織爲層次性的樹。一般他們並不修改方法調用，而只是將其沿組合對象與子對象的鏈向下傳遞，直到到達被落實在葉對象上。裝飾模式也是一種結構模式，他並不是用於組織對象，而是用於在不修改現有對象或從其派生子類的前提下爲其增添職責，建立裝飾者的目的就在於對方法進行修改。

    5）擴展：若是你以爲裝飾模式就只是改變方法那點功能的話，那你就太膚淺了，緣由是咱們還能夠在裝飾類中新增一些接口以外的方法，那麼這些方法就是新增的功能，這個就是java中IO使用的裝飾模式。

16 代理模式

    1）概念：代理模式最基本的形式是對訪問進行控制，代理對象和被代理對象實現同一個接口，客戶端只與代理對象打交道，調用的是代理對象的接口，然而實際上工做的是被代理對象（本體）工做，本體纔是負責執行所分派的任務那個對象。代理對象所作的不外乎控制本體的訪問，注意：代理對象並不會在另外一個對象的基礎上添加方法或修改其方法（這是與裝飾模式的區別），也不會簡化那個對象的接口（這是與門面模式的區別）。代理對象與本體實現同一個接口，客戶端對代理的調用都會被傳到本體對應的接口中。

    2）分類：虛擬代理，遠程代理，保護代理

            A 虛擬代理：代理模式一開始是把本體實例化放在代理對象實例化的同時實例的（代理類的構造函數中實例化本體對象），若是使用虛擬代理的話就是在實現接口的全部方法中作一個判斷，若是本體對象爲空的就實例。也就是說吧本體實例化的過程放在了等須要調用到本體時才實例化。

            B 遠程代理：用戶訪問另外一個環境中的對象，javascript中不多使用或實現。

            C 保護代理：根據用戶身份來控制代理對本體的訪問，這個在javascript中很難作到，通常是在java中實現。

    3）對比：

                    

17 亨元模式

    1）概念：亨元模式用於減小應用程序所須要對象的數量，這是經過將對象的內部狀態劃分爲內在數據和外在數據兩類實現的。內在數據是指類的內部方法所須要的信息，沒有這種數據的話類就不能正常運做，換句話說內部數據就是這個類必須擁有的屬性，因此全部的對象基本上都擁有這些屬性，並且屬性的值也都是固定的那麼一些值，從而咱們能夠把這些值分別建立對象用來外部共享，也就是享元對象。外在數據則是能夠從類身上剝離並存儲在其外部的信息，換句話說外部信息實際上是這個對象並非很緊密的一些屬性，但同時倒是這個對象獨一無二用以區別其餘對象的屬性。

    2）思想：將內在狀態相同的全部對象替換爲同一個共享對象，外在狀態的屬性是不可能相同的，因此就是用以區分對象的，所以外在狀態必須做爲某些信息被封裝。由於內在狀態對象被共享因此使用工廠模式來控制對象的生成。形象的例子就是：一盤圍棋的全部棋子：把棋子的顏色做爲內在屬性，因此只可能有兩個對象黑和白，而後把對象的位置做爲外部屬性，那就是惟一的，能夠用參數保存也能夠重新定義對象。

    3）做用：就是減小對象，其實很複雜。

    4）總結：在java中有一個抽象的亨元角色（定義了共享對象的全部接口），有多個具體的亨元角色（實現抽象亨元角色，同時定義本身的方法），有一個工廠類（根據外部判斷內存中是否已經實例化過具體共享的亨元角色對象，若是有就不實例化直接返回，不然實例化在返回）。

18 命令模式

    1）概念：通常狀況下，「行爲請求者」與「行爲實現者」一般呈現一種「緊耦合」，也就是發送命令和執行命令都是封裝在一處完成。但在某些場合，如何將「行爲請求者」與「行爲實現者」解耦？將一組行爲抽象爲對象，同時將一組實現也抽象爲對象，達到實現兩者之間的鬆耦合關係。

    2）思想：首先咱們要定義一個抽象接口，他就是抽象命令角色，它定義了命令的基本操做，其次就是具體命令角色，咱們把具體的命令抽象爲一個類，這個類經過實現接口中的方法來完成命令的處理，說道命令的處理天然不是具體命令類所要作的事情，那麼命令類中應該有處理命令對象的引用，那個對象就是接收者，接收者應該也要實現抽象命令角色，這樣就相似於代理模式的調用。那麼命令的生成又是誰來呢，那就是客戶端，客戶端發送一個命令（初始化一個命令對象），而後調用發送給Invoker（命令調用）對象，天然客戶端要把所建立的命令對象一同給命令調用者，那麼命令調用者擁有命令對象的引用，在內部調用命令對象的方法，從而就執行了整個命令的完成。

    3）流程：客戶端 -----》發出命令（初始化命令對象）----》傳遞給Invoker------》Invoker調用命令-------》命令調用行爲實現者----》處理。

    4）我的理解：這個不就是一個代理模式嗎，只是相對代理而言，命令角色有種層層傳遞到最底層的感受罷了。

19 觀察者模式

    1）概念：一個目標物件管理全部相依於它的觀察者物件，而且在它自己的狀態改變時主動發出通知。此種模式一般被用來實現事件處理系統。

    2）思想：首先咱們定義一個觀察者接口，聲明觀察者共有的方法。而後咱們就能夠編寫具體觀察者角色實現抽象接口。這邊就是被觀察者，他也是一個抽象接口，聲明諸多與觀察者相關的方法，好比撤銷觀察者，註冊觀察者等，而後一樣編寫具體的被觀察者實現抽象接口，最重要的是被觀察者中有一個抽象觀察者的集合引用，用來存放已經註冊的觀察者，一旦有事情通知觀察者就只需遍歷集合而後調用觀察者對象的方法處理。

    3）javascript中的例子就是事件處理器（一個被觀察者只有一個觀察者）與事件監聽器（一個被觀察者能夠擁有多個觀察者），他們都是觀察者模式。

20 責任鏈模式

    1）概念：用來消除請求的發送者和接收者之間的耦合，這是經過實現一個由隱式的請求進行處理的對象組成的鏈而作到的。鏈中每一個對象能夠處理請求，也能夠將其傳給下一個對象

    2）思想：一個簡單的客戶類就是請求的發送者，發送者的任務就是建立命令或說發出請求；其次就是接收者或者說是一個命令的處理者（鏈子），他就是核心，那麼咱們首先聲明一個抽象接口，定義鏈子的共有的方法，而後全部的鏈子實現這個接口中的方法，而且每一個鏈子都有一個該接口類型的引用，用來存放下一個鏈子的對象。那麼命令處理就是這樣的，客戶端建立了一個命令，而後發送出這個命令，以後就是由鏈子處理，若是開頭的鏈子可以處理那麼我就返回結果給客戶端，若是不能處理命令那就把命令繼續傳遞給下一個鏈子，讓下一個處理，直處處理完成。

    3）對比：命令模式其實也是這樣的一個流程，惟一兩者的差別就在於處理，命令模式一直是把命令發送給最底層的來處理，然而責任鏈則不是，他是隻要有一個鏈子可以處理命令就能夠不用執行下面的流程了。

    4）例子：javascript 中的冒泡模型就是這個原理，還有一個很突出的就是攔截器，tomcat中設置的攔截器filter就是這個原理，使用chain.doFilter();執行下一個攔截器，不然直接熱return。