設計模式的六大原則

• 1.開閉原則（Open Close Principle）
  
  • 開閉原則的意思是：對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，實現一個熱插拔的效果。簡言之，是為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類。
• 2.里氏代換原則（Liskov Substitution Principle）
  
  • 里氏代換原則是面向物件設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。LSP 是繼承複用的基石，只有當派生類可以替換掉基類，且軟體單位的功能不受到影響時，基類才能真正被複用，而派生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化，而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。
• 3.依賴倒轉原則（Dependence Inversion Principle）
  
  • 這個原則是開閉原則的基礎，具體內容：針對介面程式設計，依賴於抽象而不依賴於具體。
• 4.介面隔離原則（Interface Segregation Principle）
  
  • 這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。它還有另外一個意思是：降低類之間的耦合度。由此可見，其實設計模式就是從大型軟體架構出發、便於升級和維護的軟體設計思想，它強調降低依賴，降低耦合。
• 5.迪米特法則，又稱最少知道原則（Demeter Principle）
  
  • 最少知道原則是指：一個實體應當儘量少地與其他實體之間發生相互作用，使得系統功能模組相對獨立。
• 6.合成複用原則（Composite Reuse Principle）
  
  • 合成複用原則是指：儘量使用合成/聚合的方式，而不是使用繼承。

建立型模式

• 這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用 new 運算子直接例項化物件。這使得程式在判斷針對某個給定例項需要建立哪些物件時更加靈活。

工廠模式（Factory Pattern）

• 意圖：定義一個建立物件的介面，讓其子類自己決定例項化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。

• 何時使用：我們明確地計劃不同條件下建立不同例項時。

• 如何解決：讓其子類實現工廠介面，返回的也是一個抽象的產品。

• 優點： 1、一個呼叫者想建立一個物件，只要知道其名稱就可以了。 2、擴充套件性高，如果想增加一個產品，只要擴充套件一個工廠類就可以。 3、遮蔽產品的具體實現，呼叫者只關心產品的介面。

• 缺點：每次增加一個產品時，都需要增加一個具體類和物件實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。

• 使用場景： 1、日誌記錄器：記錄可能記錄到本地硬碟、系統事件、遠端伺服器等，使用者可以選擇記錄日誌到什麼地方。 2、資料庫訪問，當用戶不知道最後系統採用哪一類資料庫，以及資料庫可能有變化時。 3、設計一個連線伺服器的框架，需要三個協議，”POP3”、”IMAP”、”HTTP”，可以把這三個作為產品類，共同實現一個介面。

• 注意事項：作為一種建立類模式，在任何需要生成複雜物件的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜物件適合使用工廠模式，而簡單物件，特別是只需要通過 new 就可以完成建立的物件，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。
  

  

抽象工廠模式

• 意圖：提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。

• 主要解決：主要解決介面選擇的問題。

• 何時使用：系統的產品有多於一個的產品族，而系統只消費其中某一族的產品。

• 應用例項：工作了，為了參加一些聚會，肯定有兩套或多套衣服吧，比如說有商務裝（成套，一系列具體產品）、時尚裝（成套，一系列具體產品），甚至對於一個家庭來說，可能有商務女裝、商務男裝、時尚女裝、時尚男裝，這些也都是成套的，即一系列具體產品。假設一種情況（現實中是不存在的，要不然，沒法進入共產主義了，但有利於說明抽象工廠模式），在您的家中，某一個衣櫃（具體工廠）只能存放某一種這樣的衣服（成套，一系列具體產品），每次拿這種成套的衣服時也自然要從這個衣櫃中取出了。用 OO 的思想去理解，所有的衣櫃（具體工廠）都是衣櫃類的（抽象工廠）某一個，而每一件成套的衣服又包括具體的上衣（某一具體產品），褲子（某一具體產品），這些具體的上衣其實也都是上衣（抽象產品），具體的褲子也都是褲子（另一個抽象產品）。

• 優點：當一個產品族中的多個物件被設計成一起工作時，它能保證客戶端始終只使用同一個產品族中的物件。

• 缺點：產品族擴充套件非常困難，要增加一個系列的某一產品，既要在抽象的 Creator 里加程式碼，又要在具體的裡面加程式碼。

• 使用場景： 1、QQ 換面板，一整套一起換。 2、生成不同作業系統的程式。
  

• Sunny軟體公司欲開發一套介面面板庫設計
  
• Sunny軟體公司欲開發一套介面面板庫架構
  
• 抽象工廠模式(Abstract Factory Pattern)：提供一個建立一系列相關或相互依賴物件的介面，而無須指定它們具體的類。抽象工廠模式又稱為Kit模式，它是一種物件建立型模式。
• 在抽象工廠模式中，每一個具體工廠都提供了多個工廠方法用於產生多種不同型別的產品，這些產品構成了一個產品族，抽象工廠模式結構如圖所示：
  
• 在抽象工廠模式結構圖中包含如下幾個角色：
  
  • AbstractFactory（抽象工廠）：它聲明瞭一組用於建立一族產品的方法，每一個方法對應一種產品。
  • ConcreteFactory（具體工廠）：它實現了在抽象工廠中宣告的建立產品的方法，生成一組具體產品，這些產品構成了一個產品族，每一個產品都位於某個產品等級結構中。
  • AbstractProduct（抽象產品）：它為每種產品宣告介面，在抽象產品中聲明瞭產品所具有的業務方法。
  • ConcreteProduct（具體產品）：它定義具體工廠生產的具體產品物件，實現抽象產品介面中宣告的業務方法。
• Sunny公司開發人員使用抽象工廠模式來重構介面面板庫的設計，其基本結構如圖所示：
  

//在本例項中我們對程式碼進行了大量簡化，實際使用時，介面元件的初始化程式碼較為複雜，還需要使用JDK中一些已有類，為了突出核心程式碼，在此只提供框架程式碼和演示輸出。  
//按鈕介面：抽象產品  
interface Button {  
    public void display();  
}  

//Spring按鈕類：具體產品  
class SpringButton implements Button {  
    public void display() {  
        System.out.println("顯示淺綠色按鈕。");  
    }  
}  

//Summer按鈕類：具體產品  
class SummerButton implements Button {  
    public void display() {  
        System.out.println("顯示淺藍色按鈕。");  
    }     
}  

//文字框介面：抽象產品  
interface TextField {  
    public void display();  
}  

//Spring文字框類：具體產品  
class SpringTextField implements TextField {  
    public void display() {  
        System.out.println("顯示綠色邊框文字框。");  
    }  
}  

//Summer文字框類：具體產品  
class SummerTextField implements TextField {  
    public void display() {  
        System.out.println("顯示藍色邊框文字框。");  
    }     
}  

//組合框介面：抽象產品  
interface ComboBox {  
    public void display();  
}  

//Spring組合框類：具體產品  
class SpringComboBox implements ComboBox {  
    public void display() {  
        System.out.println("顯示綠色邊框組合框。");  
    }  
}  

//Summer組合框類：具體產品  
class SummerComboBox implements ComboBox {  
    public void display() {  
        System.out.println("顯示藍色邊框組合框。");  
    }     
}  

//介面面板工廠介面：抽象工廠  
interface SkinFactory {  
    public Button createButton();  
    public TextField createTextField();  
    public ComboBox createComboBox();  
}  

//Spring面板工廠：具體工廠  
class SpringSkinFactory implements SkinFactory {  
    public Button createButton() {  
        return new SpringButton();  
    }  

    public TextField createTextField() {  
        return new SpringTextField();  
    }  

    public ComboBox createComboBox() {  
        return new SpringComboBox();  
    }  
}  

//Summer面板工廠：具體工廠  
class SummerSkinFactory implements SkinFactory {  
    public Button createButton() {  
        return new SummerButton();  
    }  

    public TextField createTextField() {  
        return new SummerTextField();  
    }  

    public ComboBox createComboBox() {  
        return new SummerComboBox();  
    }  
}

單例設計模式

• 意圖：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。

• 主要解決：一個全域性使用的類頻繁地建立與銷燬。

• 何時使用：當您想控制例項數目，節省系統資源的時候。

• 如何解決：判斷系統是否已經有這個單例，如果有則返回，如果沒有則建立。

• 關鍵程式碼：建構函式是私有的。

• 應用例項： 1、一個黨只能有一個主席。 2、Windows 是多程序多執行緒的，在操作一個檔案的時候，就不可避免地出現多個程序或執行緒同時操作一個檔案的現象，所以所有檔案的處理必須通過唯一的例項來進行。 3、一些裝置管理器常常設計為單例模式，比如一個電腦有兩臺印表機，在輸出的時候就要處理不能兩臺印表機列印同一個檔案。

• 優點： 1、在記憶體裡只有一個例項，減少了記憶體的開銷，尤其是頻繁的建立和銷燬例項（比如管理學院首頁頁面快取）。 2、避免對資源的多重佔用（比如寫檔案操作）。

• 缺點：沒有介面，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來例項化。

• 使用場景： 1、要求生產唯一序列號。 2、WEB 中的計數器，不用每次重新整理都在資料庫里加一次，用單例先快取起來。 3、建立的一個物件需要消耗的資源過多，比如 I/O 與資料庫的連線等。

• 注意事項：getInstance() 方法中需要使用同步鎖 synchronized (Singleton.class) 防止多執行緒同時進入造成 instance 被多次例項化。
  

• Sunny公司開發人員通過分析和權衡，決定使用單例模式來設計該負載均衡器，結構圖如圖所示：
  
• 懶漢式完美實現執行緒安全
  
  • 假如在某一瞬間執行緒A和執行緒B都在呼叫getInstance()方法，此時instance物件為null值，均能通過instance == null的判斷。由於實現了synchronized加鎖機制，執行緒A進入synchronized鎖定的程式碼中執行例項建立程式碼，執行緒B處於排隊等待狀態，必須等待執行緒A執行完畢後才可以進入synchronized鎖定程式碼。但當A執行完畢時，執行緒B並不知道例項已經建立，將繼續建立新的例項，導致產生多個單例物件，違背單例模式的設計思想，因此需要進行進一步改進，在synchronized中再進行一次(instance == null)判斷，這種方式稱為雙重檢查鎖定(Double-Check Locking)。使用雙重檢查鎖定實現的懶漢式單例類完整程式碼如下所示：

class LazySingleton {   
    private volatile static LazySingleton instance = null;   

    private LazySingleton() { }   

    public static LazySingleton getInstance() {   
        //第一重判斷  
        if (instance == null) {  
            //鎖定程式碼塊  
            synchronized (LazySingleton.class) {  
                //第二重判斷  
                if (instance == null) {  
                    instance = new LazySingleton(); //建立單例例項  
                }  
            }  
        }  
        return instance;   
    }  
}

• 餓漢式單例類不能實現延遲載入，不管將來用不用始終佔據記憶體；懶漢式單例類執行緒安全控制煩瑣，而且效能受影響。可見，無論是餓漢式單例還是懶漢式單例都存在這樣那樣的問題，有沒有一種方法，能夠將兩種單例的缺點都克服，而將兩者的優點合二為一呢？答案是：Yes！下面我們來學習這種更好的被稱之為Initialization Demand Holder (IoDH)的技術。
• 在IoDH中，我們在單例類中增加一個靜態(static)內部類，在該內部類中建立單例物件，再將該單例物件通過getInstance()方法返回給外部使用，實現程式碼如下所示：

//Initialization on Demand Holder  
class Singleton {  
    private Singleton() {  
    }  

    private static class HolderClass {  
            private final static Singleton instance = new Singleton();  
    }  

    public static Singleton getInstance() {  
        return HolderClass.instance;  
    }  

    public static void main(String args[]) {  
        Singleton s1, s2;   
            s1 = Singleton.getInstance();  
        s2 = Singleton.getInstance();  
        System.out.println(s1==s2);  
    }  
}

原型模式

• 原型模式（Prototype Pattern）是用於建立重複的物件，同時又能保證效能。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。

• 意圖：用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。

• 主要解決：在執行期建立和刪除原型。

• 何時使用： 1、當一個系統應該獨立於它的產品建立，構成和表示時。 2、當要例項化的類是在執行時刻指定時，例如，通過動態裝載。 3、為了避免建立一個與產品類層次平行的工廠類層次時。 4、當一個類的例項只能有幾個不同狀態組合中的一種時。建立相應數目的原型並克隆它們可能比每次用合適的狀態手工例項化該類更方便一些。

• 如何解決：利用已有的一個原型物件，快速地生成和原型物件一樣的例項。

• 關鍵程式碼： 1、實現克隆操作，在 JAVA 繼承 Cloneable，重寫 clone()，在 .NET 中可以使用 Object 類的 MemberwiseClone() 方法來實現物件的淺拷貝或通過序列化的方式來實現深拷貝。 2、原型模式同樣用於隔離類物件的使用者和具體型別（易變類）之間的耦合關係，它同樣要求這些”易變類”擁有穩定的介面。

• 應用例項： 1、細胞分裂。 2、JAVA 中的 Object clone() 方法。

• 優點： 1、效能提高。 2、逃避建構函式的約束。

• 缺點： 1、配備克隆方法需要對類的功能進行通盤考慮，這對於全新的類不是很難，但對於已有的類不一定很容易，特別當一個類引用不支援序列化的間接物件，或者引用含有迴圈結構的時候。 2、必須實現 Cloneable 介面。

• 使用場景： 1、資源優化場景。 2、類初始化需要消化非常多的資源，這個資源包括資料、硬體資源等。 3、效能和安全要求的場景。 4、通過 new 產生一個物件需要非常繁瑣的資料準備或訪問許可權，則可以使用原型模式。 5、一個物件多個修改者的場景。 6、一個物件需要提供給其他物件訪問，而且各個呼叫者可能都需要修改其值時，可以考慮使用原型模式拷貝多個物件供呼叫者使用。 7、在實際專案中，原型模式很少單獨出現，一般是和工廠方法模式一起出現，通過 clone 的方法建立一個物件，然後由工廠方法提供給呼叫者。原型模式已經與 Java 融為渾然一體，大家可以隨手拿來使用。

• 注意事項：與通過對一個類進行例項化來構造新物件不同的是，原型模式是通過拷貝一個現有物件生成新物件的。淺拷貝實現 Cloneable，重寫，深拷貝是通過實現 Serializable 讀取二進位制流。

• 淺克隆：
  
  • 在淺克隆中，如果原型物件的成員變數是值型別，將複製一份給克隆物件；如果原型物件的成員變數是引用型別，則將引用物件的地址複製一份給克隆物件，也就是說原型物件和克隆物件的成員變數指向相同的記憶體地址。簡單來說，在淺克隆中，當物件被複制時只複製它本身和其中包含的值型別的成員變數，而引用型別的成員物件並沒有複製
    
    
• 2.深克隆
  
  • 在深克隆中，無論原型物件的成員變數是值型別還是引用型別，都將複製一份給克隆物件，深克隆將原型物件的所有引用物件也複製一份給克隆物件。簡單來說，在深克隆中，除了物件本身被複制外，物件所包含的所有成員變數也將複製
    
    

//使用序列化技術實現深克隆
       public WeeklyLog deepClone() throws  IOException, ClassNotFoundException, OptionalDataException
       {
              //將物件寫入流中
              ByteArrayOutputStream bao=new  ByteArrayOutputStream();
              ObjectOutputStream oos=new  ObjectOutputStream(bao);
              oos.writeObject(this);

              //將物件從流中取出
              ByteArrayInputStream bis=new  ByteArrayInputStream(bao.toByteArray());
              ObjectInputStream ois=new  ObjectInputStream(bis);
              return  (WeeklyLog)ois.readObject();
       }

• 使用帶原型管理器的原型模式實現公文管理器的設計
  

import java.util.*;

//抽象公文介面，也可定義為抽象類，提供clone()方法的實現，將業務方法宣告為抽象方法
interface OfficialDocument extends Cloneable {
    public OfficialDocument clone();

    public void display();
}

//可行性分析報告(Feasibility Analysis Report)類
class FAR implements OfficialDocument {
    public OfficialDocument clone() {
        OfficialDocument far = null;
        try {
            far = (OfficialDocument) super.clone();
        } catch (CloneNotSupportedException e) {
            System.out.println("不支援複製！");
        }
        return far;
    }

    public void display() {
        System.out.println("《可行性分析報告》");
    }
}

//軟體需求規格說明書(Software Requirements Specification)類
class SRS implements OfficialDocument {
    public OfficialDocument clone() {
        OfficialDocument srs = null;
        try {
            srs = (OfficialDocument) super.clone();
        } catch (CloneNotSupportedException e) {
            System.out.println("不支援複製！");
        }
        return srs;
    }

    public void display() {
        System.out.println("《軟體需求規格說明書》");
    }
}

//原型管理器（使用餓漢式單例實現）
class PrototypeManager {
    //定義一個Hashtable，用於儲存原型物件
    private Hashtable ht = new Hashtable();
    private static PrototypeManager pm = new PrototypeManager();

    //為Hashtable增加公文物件   
    private PrototypeManager() {
        ht.put("far", new FAR());
        ht.put("srs", new SRS());
    }

    //增加新的公文物件
    public void addOfficialDocument(String key, OfficialDocument doc) {
        ht.put(key, doc);
    }

    //通過淺克隆獲取新的公文物件
    public OfficialDocument getOfficialDocument(String key) {
        return ((OfficialDocument) ht.get(key)).clone();
    }

    public static PrototypeManager getPrototypeManager() {
        return pm;
    }
}

建立者模式

• 建造者模式又稱為生成器模式，它是一種較為複雜、使用頻率也相對較低的建立型模式。建造者模式為客戶端返回的不是一個簡單的產品，而是一個由多個部件組成的複雜產品。

• 意圖：將一個複雜的構建與其表示相分離，使得同樣的構建過程可以建立不同的表示。

• 主要解決：主要解決在軟體系統中，有時候面臨著”一個複雜物件”的建立工作，其通常由各個部分的子物件用一定的演算法構成；由於需求的變化，這個複雜物件的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的演算法卻相對穩定。

• 何時使用：一些基本部件不會變，而其組合經常變化的時候。

• 如何解決：將變與不變分離開。

• 關鍵程式碼：建造者：建立和提供例項，導演：管理建造出來的例項的依賴關係。

• 應用例項： 1、去肯德基，漢堡、可樂、薯條、炸雞翅等是不變的，而其組合是經常變化的，生成出所謂的”套餐”。 2、JAVA 中的 StringBuilder。

• 優點： 1、建造者獨立，易擴充套件。 2、便於控制細節風險。

• 缺點： 1、產品必須有共同點，範圍有限制。 2、如內部變化複雜，會有很多的建造類。

• 使用場景： 1、需要生成的物件具有複雜的內部結構。 2、需要生成的物件內部屬性本身相互依賴。

• 注意事項：與工廠模式的區別是：建造者模式更加關注與零件裝配的順序。
  

• 建造者模式(Builder Pattern)：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。建造者模式是一種物件建立型模式。

• 建造者模式一步一步建立一個複雜的物件，它允許使用者只通過指定複雜物件的型別和內容就可以構建它們，使用者不需要知道內部的具體構建細節。
  

• demo：

package com.hyman.date0625_0701.designpatterns.builder;

/**
 * @program: javalearning
 * @Date: 2018/6/25 9:58
 * @Author: hyman.hu
 * @Description:
 */
public class Student {

    private String userName;
    private String email;
    private Integer age;
    private Integer sex;

    public static class StudentBuilder {

        private final Student instance;

        public StudentBuilder() {
            this.instance = new Student();
        }

        public StudentBuilder withUserName(String userName) {
            instance.userName = userName;
            return this;
        }

        public StudentBuilder withEmail(String email) {
            instance.email = email;
            return this;
        }

        public StudentBuilder withAge(Integer age) {
            instance.age = age;
            return this;
        }

        public StudentBuilder withSex(Integer sex) {
            instance.sex = sex;
            return this;
        }

        public Student build() {
            return instance;
        }

    }

    public static StudentBuilder newBuilder() {
        return new StudentBuilder();
    }

    public String getUserName() {
        return userName;
    }

    public String getEmail() {
        return email;
    }

    public Integer getAge() {
        return age;
    }

    public Integer getSex() {
        return sex;
    }

    @Override
    public String toString() {
        return "Student{" +
                "userName='" + userName + '\'' +
                ", email='" + email + '\'' +
                ", age=" + age +
                ", sex=" + sex +
                '}';
    }
}

• 測試程式碼：

@Test
    public void testBuilder(){
        Student student = Student.newBuilder()
                .withUserName("hyman")
                .withEmail("[email protected]")
                .withAge(26)
                .withSex(1)
                .build();
        System.out.println(student);
    }