從今天起（2017.2.14），我要開始系統認真的啃基礎，堅持下去，每天進步一點點。

一、什麼是設計者模式（what）?

最早提出“設計模式”概念的是建築設計大師亞力山大Alexander。在他的《建築的永恆之道》裡這樣描述：模式是一條由三個部分組成的通用規則：它表示了一個特定環境、一類問題和一個解決方案之間的關係。每一個模式描述了一個不斷重複發生的問題，以及該問題解決方案的核心設計。設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。

二、設計模式的分類

總體來說設計模式分為三大類：建立型模式用來處理物件的建立過程；結構型模式用來處理類或者物件的組合；行為型模式用來對類或物件怎樣互動和怎樣分配職責進行描述。
建立型模式

用來處理物件的建立過程，主要包含以下5種設計模式：
工廠方法模式（Factory Method Pattern）
抽象工廠模式（Abstract Factory Pattern）
建造者模式（Builder Pattern搜尋）
原型模式（Prototype Pattern）
單例模式（Singleton Pattern）
 
結構型模式用來處理類或者物件的組合，主要包含以下7種設計模式：
介面卡模式（Adapter Pattern）
橋接模式（Bridge Pattern）
組合模式（Composite Pattern）
裝飾者模式（Decorator Pattern）
外觀模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
 
行為型模式

用來對類或物件怎樣互動和怎樣分配職責進行描述，主要包含以下11種設計模式：
責任鏈模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
直譯器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
備忘錄模式（Memento Pattern）
觀察者模式（Observer Pattern）
狀態模式（State Pattern）
策略模式（Strategy Pattern）
模板方法模式（Template Method Pattern）
訪問者模式（Visitor Pattern）
其實還有兩類：併發型模式和執行緒池模式。用一個圖片來整體描述一下：

三、設計模式六大原則

總原則－開閉原則（Open Close Principle）
開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。

1、單一職責原則
不要存在多於一個導致類變更的原因，也就是說每個類應該實現單一的職責，否則就應該把類拆分。
2、里氏代換原則（Liskov Substitution Principle）
任何基類可以出現的地方，子類一定可以出現。里氏替換原則是繼承複用的基石，只有當衍生類可以替換基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。
里氏代換原則是對“開-閉”原則的補充。實現“開閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。里氏替換原則中，子類對父類的方法儘量不要重寫和過載。因為父類代表了定義好的結構，通過這個規範的介面與外界互動，子類不應該隨便破壞它。
3、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對介面程式設計，依賴於抽象而不依賴於具體。
4、介面隔離原則（Interface Segregation Principle）
每個介面中不存在子類用不到卻必須實現的方法，如果不然，就要將介面拆分。使用多個隔離的介面，比使用單個介面（多個介面方法集合到一個的介面）要好。所以上文中多次出現：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什麼叫最少知道原則，就是說：一個實體應當儘量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。一個類對自己依賴的類知道的越少越好。無論被依賴的類多麼複雜，都應該將邏輯封裝在方法的內部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。
最少知道原則的另一個表達方式是：只與直接的朋友通訊。類之間只要有耦合關係，就叫朋友關係。耦合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法引數、方法返回值中的類為直接朋友。區域性變數、臨時變數則不是直接的朋友。我們要求陌生的類不要作為區域性變量出現在類中。
6、合成複用原則（Composite Reuse Principle）
原則是儘量使用合成/聚合的方式，而不是使用繼承。

四、java23種設計模式之建立型

1、工廠方法模式

場景問題
　　舉個生活中常見的例子——組裝電腦，我們在組裝電腦的時候，通常需要選擇一系列的配件，比如CPU、硬碟、記憶體、主機板、電源、機箱等。為討論使用簡單點，只考慮選擇CPU和主機板的問題。
　　事實上，在選擇CPU的時候，面臨一系列的問題，比如品牌、型號、針腳數目、主頻等問題，只有把這些問題都確定下來，才能確定具體的CPU。
　　同樣，在選擇主機板的時候，也有一系列問題，比如品牌、晶片組、整合晶片、匯流排頻率等問題，也只有這些都確定了，才能確定具體的主機板。

對於裝機工程師而言，他只知道組裝一臺電腦，需要相應的配件，但是具體使用什麼樣的配件，還得由客戶說了算。也就是說裝機工程師只是負責組裝，而客戶負責選擇裝配所需要的具體的配件。因此，當裝機工程師為不同的客戶組裝電腦時，只需要根據客戶的裝機方案，去獲取相應的配件，然後組裝即可。

原始碼
CPU介面與具體實現

public interface Cpu {
    public void calculate();
}

public class IntelCpu implements Cpu {
    /**
     * CPU的針腳數
     */
    private int pins = 0;
    public  IntelCpu(int pins){
        this.pins = pins;
    }
    @Override
    public void calculate() {
        // TODO Auto-generated method stub
        System.out.println("Intel CPU的針腳數：" + pins);
    }

}

public class AmdCpu implements Cpu {
    /**
     * CPU的針腳數
     */
    private int pins = 0;
    public  AmdCpu(int pins){
        this.pins = pins;
    }
    @Override
    public void calculate() {
        // TODO Auto-generated method stub
        System.out.println("AMD CPU的針腳數：" + pins);
    }
}

主機板介面與具體實現

public interface Mainboard {
    public void installCPU();
}

public class IntelMainboard implements Mainboard {
    /**
     * CPU插槽的孔數
     */
    private int cpuHoles = 0;
    /**
     * 構造方法，傳入CPU插槽的孔數
     * @param cpuHoles
     */
    public IntelMainboard(int cpuHoles){
        this.cpuHoles = cpuHoles;
    }
    @Override
    public void installCPU() {
        // TODO Auto-generated method stub
        System.out.println("Intel主機板的CPU插槽孔數是：" + cpuHoles);
    }

}

public class AmdMainboard implements Mainboard {
    /**
     * CPU插槽的孔數
     */
    private int cpuHoles = 0;
    /**
     * 構造方法，傳入CPU插槽的孔數
     * @param cpuHoles
     */
    public AmdMainboard(int cpuHoles){
        this.cpuHoles = cpuHoles;
    }
    @Override
    public void installCPU() {
        // TODO Auto-generated method stub
        System.out.println("AMD主機板的CPU插槽孔數是：" + cpuHoles);
    }
}

CPU與主機板工廠類

public class CpuFactory {
    public static Cpu createCpu(int type){
        Cpu cpu = null;
        if(type == 1){
            cpu = new IntelCpu(755);
        }else if(type == 2){
            cpu = new AmdCpu(938);
        }
        return cpu;
    }
}

public class MainboardFactory {
    public static Mainboard createMainboard(int type){
        Mainboard mainboard = null;
        if(type == 1){
            mainboard = new IntelMainboard(755);
        }else if(type == 2){
            mainboard = new AmdMainboard(938);
        }
        return mainboard;
    }
}

裝機工程師類與客戶類執行結果如下：

public class ComputerEngineer {
    /**
     * 定義組裝機需要的CPU
     */
    private Cpu cpu = null;
    /**
     * 定義組裝機需要的主機板
     */
    private Mainboard mainboard = null;
    public void makeComputer(int cpuType , int mainboard){
        /**
         * 組裝機器的基本步驟
         */
        //1:首先準備好裝機所需要的配件
        prepareHardwares(cpuType, mainboard);
        //2:組裝機器
        //3:測試機器
        //4：交付客戶
    }
    private void prepareHardwares(int cpuType , int mainboard){
        //這裡要去準備CPU和主機板的具體實現，為了示例簡單，這裡只准備這兩個
        //可是，裝機工程師並不知道如何去建立，怎麼辦呢？
        
        //直接找相應的工廠獲取
        this.cpu = CpuFactory.createCpu(cpuType);
        this.mainboard = MainboardFactory.createMainboard(mainboard);
        
        //測試配件是否好用
        this.cpu.calculate();
        this.mainboard.installCPU();
    }
}

public class Client {
    public static void main(String[]args){
        ComputerEngineer cf = new ComputerEngineer();
        cf.makeComputer(1,1);
    }
}

執行結果如下：

觀察上面結果就會看出問題。客戶選擇的是Intel的CPU針腳數為755，而選擇的主機板是AMD，主機板上的CPU插孔是938，根本無法組裝，這就是沒有維護配件之間的關係造成的。該怎麼解決這個問題呢？

2、抽象工廠模式

那麼，是否可以使用同一個工廠等級結構來對付這些相同或者極為相似的產品等級結構呢？當然可以的，而且這就是抽象工廠模式的好處。同一個工廠等級結構負責三個不同產品等級結構中的產品物件的建立。

可以看出，一個工廠等級結構可以創建出分屬於不同產品等級結構的一個產品族中的所有物件。顯然，這時候抽象工廠模式比簡單工廠模式、工廠方法模式更有效率。對應於每一個產品族都有一個具體工廠。而每一個具體工廠負責建立屬於同一個產品族，但是分屬於不同等級結構的產品。

由於這兩個產品族的等級結構相同，因此使用同一個工廠族也可以處理這兩個產品族的建立問題，這就是抽象工廠模式。

根據產品角色的結構圖，就不難給出工廠角色的結構設計圖

可以看出，每一個工廠角色都有兩個工廠方法，分別負責建立分屬不同產品等級結構的產品物件

在什麼情況下應當使用抽象工廠模式
　　1.一個系統不應當依賴於產品類例項如何被建立、組合和表達的細節，這對於所有形態的工廠模式都是重要的。


　　2.這個系統的產品有多於一個的產品族，而系統只消費其中某一族的產品。


　　3.同屬於同一個產品族的產品是在一起使用的，這一約束必須在系統的設計中體現出來。（比如：Intel主機板必須使用Intel CPU、Intel晶片組）


　　4.系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴於實現。

抽象工廠模式的優點
1、分離介面和實現
　　客戶端使用抽象工廠來建立需要的物件，而客戶端根本就不知道具體的實現是誰，客戶端只是面向產品的介面程式設計而已。也就是說，客戶端從具體的產品實現中解耦。

2、使切換產品族變得容易
　　因為一個具體的工廠實現代表的是一個產品族，比如上面例子的從Intel系列到AMD系列只需要切換一下具體工廠。


抽象工廠模式的缺點
不太容易擴充套件新的產品
　　如果需要給整個產品族新增一個新的產品，那麼就需要修改抽象工廠，這樣就會導致修改所有的工廠實現類。

http://www.cnblogs.com/java-my-life/archive/2012/03/28/2418836.html

3、單例模式

單例模式有以下特點：
1、單例類只能有一個例項。
2、單例類必須自己建立自己的唯一例項。

3、單例類必須給所有其他物件提供這一例項。

模式：根據例項化物件時機不同分為懶漢模式與餓漢模式。餓漢模式是單例類被載入時候就例項化一個物件交給自己的引用；懶漢模式時在呼叫取得例項方法的時候才會例項化物件。

首先要解釋一下什麼是延遲載入，延遲載入就是等到真真使用的時候才去建立例項，不用時不要去建立。從速度和反應時間角度來講，非延遲載入（又稱餓漢式）好；從資源利用效率上說，延遲載入（又稱懶漢式）好。

使用場景

系統只需要一個例項物件。
需要頻繁例項化且銷燬的物件。
建立物件時耗時過多或者耗資源過多，但又經常用到的物件。
有狀態的物件。
頻繁訪問資料庫或檔案的物件。

反過來說，如果一個類可以有幾個例項共存，那麼就沒有必要使用單例類。java語言中的Runtime物件就是一個單例模式

這樣的模式有幾個好處：
1、某些類建立比較頻繁，對於一些大型的物件，這是一筆很大的系統開銷。
2、省去了new操作符，降低了系統記憶體的使用頻率，減輕GC壓力。
3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以建立多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

**1、餓漢式單例

//餓漢式單例類.在類初始化時，已經自行例項化 
public class Singleton1 {
    private Singleton1() {}
    private static final Singleton1 single = new Singleton1();
    //靜態工廠方法 
    public static Singleton1 getInstance() {
        return single;
    }
}

Java語言中的單例類的一個最重要的特點是類的構造方法是私有的，從而避免外界利用構造方法直接創建出人意多飛例項。
優點：1.執行緒安全的2.在類載入的同時已經建立好一個靜態物件,呼叫時反應速度快。缺點： 資源利用效率不高，可能getInstance永遠不會執行到，但是執行了該類的其他靜態方法或者載入了該類（class.forName），那麼這個例項仍然初始化了

2、懶漢式單例

//懶漢式單例類.在第一次呼叫的時候例項化自己 
public class Singleton {
    private Singleton() {}
    private static Singleton single=null;
    //靜態工廠方法 
    public static Singleton getInstance() {
         if (single == null) {  
             single = new Singleton();
         }  
        return single;
    }
}

但是以上懶漢式單例的實現沒有考慮執行緒安全問題，它是執行緒不安全的，併發環境下很可能出現多個Singleton例項，要實現執行緒安全，有以下三種方式，都是對getInstance這個方法改造，保證了懶漢式單例的執行緒安全。

（1）在getInstance方法上加同步

public static synchronized Singleton getInstance() {
         if (single == null) {  
             single = new Singleton();
         }  
        return single;
}

執行緒安全解決了，高併發沒解決。但是，synchronized關鍵字鎖住的是這個物件，這樣的用法，在效能上會有所下降，因為每次呼叫getInstance()，都要對物件上鎖，事實上，只有在第一次建立物件的時候需要加鎖，之後就不需要了，所以，這個地方需要改進。

（2）雙重檢查鎖定

public static Singleton getInstance() {
        if (singleton == null) {  
            synchronized (Singleton.class) {  
               if (singleton == null) {  
                  singleton = new Singleton(); 
               }  
            }  
        }  
        return singleton; 
    }

似乎解決了之前提到的問題，將synchronized關鍵字加在了內部，也就是說當呼叫的時候是不需要加鎖的，只有在instance為null，並建立物件的時候才需要加鎖，效能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中建立物件和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序，也就是說有可能JVM會為新的Singleton例項分配空間，然後直接賦值給instance成員，然後再去初始化這個Singleton例項。這樣就可能出錯了，我們以A、B兩個執行緒為例：
a>A、B執行緒同時進入了第一個if判斷
b>A首先進入synchronized塊，由於instance為null，所以它執行instance = new Singleton();
c>由於JVM內部的優化機制，JVM先畫出了一些分配給Singleton例項的空白記憶體，並賦值給instance成員（注意此時JVM沒有開始初始化這個例項），然後A離開了synchronized塊。
d>B進入synchronized塊，由於instance此時不是null，因此它馬上離開了synchronized塊並將結果返回給呼叫該方法的程式。
e>此時B執行緒打算使用Singleton例項，卻發現它沒有被初始化，於是錯誤發生了。
（執行緒安全解決了，高併發解決。但假設現在有A、B執行緒同時調運getInstance，然後A進入了DBManager例項化，此時假設B已經進入if (null == mInstance)然後在等待A釋放鎖，但是問題來了，當A釋放鎖以後已經例項化了變數mInstance，B卻傻逼的不知道，然後繼續持有鎖例項化一個新的物件）

如果使用雙重檢查鎖定來實現懶漢式單例類，需要在靜態成員變數instance之前增加修飾符volatile，被volatile修飾的成員變數只能在JDK 1.5及以上版本中才能正確執行。volatile關鍵字會遮蔽Java虛擬機器所做的一些程式碼優化，會導致系統執行效率降低，所以這種寫法的單例模式也不是一種牛叉的寫法。
優點：1.資源利用率高
缺點：第一次載入是發應不快 ，由於java 記憶體模型一些原因偶爾會失敗

（3）靜態內部類：實際情況是，單例模式使用內部類來維護單例的實現，JVM內部的機制能夠保證當一個類被載入的時候，這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫getInstance的時候，JVM能夠幫我們保證instance只被建立一次，並且會保證把賦值給instance的記憶體初始化完畢，這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制，這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式：

public class Singleton {  
    private static class LazyHolder {  
       private static final Singleton INSTANCE = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
       return LazyHolder.INSTANCE;  
    }  
}

如下寫法的亮點就在於這種寫法使用了JVM本身機制保證執行緒安全問題；由於InstanceHolder是私有的，除了getInstance()之外沒有辦法訪問它，因此它是懶漢式的；同時讀取例項的時候不會進行同步，沒有效能缺陷；也不依賴JDK版本。
至於1、2、3這三種實現又有些區別，
第1種，在方法呼叫上加了同步，雖然執行緒安全了，但是每次都要同步，會影響效能，畢竟99%的情況下是不需要同步的，
第2種，在getInstance中做了兩次null檢查，確保了只有第一次呼叫單例的時候才會做同步，這樣也是執行緒安全的，同時避免了每次都同步的效能損耗
第3種，利用了classloader的機制來保證初始化instance時只有一個執行緒，所以也是執行緒安全的，同時沒有效能損耗，所以一般我傾向於使用這一種。

餓漢式和懶漢式區別
1、從名字上來說，餓漢和懶漢，
餓漢就是類一旦載入，就把單例初始化完成，保證getInstance的時候，單例是已經存在的了
而懶漢比較懶，只有當呼叫getInstance的時候，才回去初始化這個單例。
另外從以下兩點再區分以下這兩種方式：
2、執行緒安全：
餓漢式天生就是執行緒安全的，可以直接用於多執行緒而不會出現問題，
懶漢式本身是非執行緒安全的，為了實現執行緒安全有幾種寫法，分別是上面的1、2、3，這三種實現在資源載入和效能方面有些區別。
3、資源載入和效能：
餓漢式在類建立的同時就例項化一個靜態物件出來，不管之後會不會使用這個單例，都會佔據一定的記憶體，但是相應的，在第一次呼叫時速度也會更快，因為其資源已經初始化完成，
而懶漢式顧名思義，會延遲載入，在第一次使用該單例的時候才會例項化物件出來，第一次呼叫時要做初始化，如果要做的工作比較多，效能上會有些延遲，之後就和餓漢式一樣了。