1，設計模式概述

1.1 軟體設計模式的產生背景

"設計模式"最初并不是出現在軟體設計中，而是被用于建筑領域的設計中，

1977年美國著名建筑大師、加利福尼亞大學伯克利分校環境結構中心主任克里斯托夫·亞歷山大（Christopher Alexander）在他的著作《建筑模式語言：城鎮、建筑、構造》中描述了一些常見的建筑設計問題，并提出了 253 種關于對城鎮、鄰里、住宅、花園和房間等進行設計的基本模式，

1990年軟體工程界開始研討設計模式的話題，后來召開了多次關于設計模式的研討會，直到1995 年，艾瑞克·伽馬（ErichGamma）、理査德·海爾姆（Richard Helm）、拉爾夫·約翰森（Ralph Johnson）、約翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《設計模式：可復用面向物件軟體的基礎》一書，在此書中收錄了 23 個設計模式，這是設計模式領域里程碑的事件，導致了軟體設計模式的突破，這 4 位作者在軟體開發領域里也以他們的“四人組”（Gang of Four，GoF）著稱，

1.2 軟體設計模式的概念

軟體設計模式（Software Design Pattern），又稱設計模式，是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，它描述了在軟體設計程序中的一些不斷重復發生的問題，以及該問題的解決方案，也就是說，它是解決特定問題的一系列套路，是前輩們的代碼設計經驗的總結，具有一定的普遍性，可以反復使用，

1.3 學習設計模式的必要性

設計模式的本質是面向物件設計原則的實際運用，是對類的封裝性、繼承性和多型性以及類的關聯關系和組合關系的充分理解，

正確使用設計模式具有以下優點，

可以提高程式員的思維能力、編程能力和設計能力，
使程式設計更加標準化、代碼編制更加工程化，使軟體開發效率大大提高，從而縮短軟體的開發周期，
使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強，

1.4 設計模式分類

創建型模式

用于描述“怎樣創建物件”，它的主要特點是“將物件的創建與使用分離”，GoF（四人組）書中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種創建型模式，
結構型模式

用于描述如何將類或物件按某種布局組成更大的結構，GoF（四人組）書中提供了代理、配接器、橋接、裝飾、外觀、享元、組合等 7 種結構型模式，
行為型模式

用于描述類或物件之間怎樣相互協作共同完成單個物件無法單獨完成的任務，以及怎樣分配職責，GoF（四人組）書中提供了模板方法、策略、命令、職責鏈、狀態、觀察者、中介者、迭代器、訪問者、備忘錄、解釋器等 11 種行為型模式，

2，UML圖

統一建模語言（Unified Modeling Language，UML）是用來設計軟體的可視化建模語言，它的特點是簡單、統一、圖形化、能表達軟體設計中的動態與靜態資訊，

UML 從目標系統的不同角度出發，定義了用例圖、類圖、物件圖、狀態圖、活動圖、時序圖、協作圖、構件圖、部署圖等 9 種圖，

2.1 類圖概述

類圖(Class diagram)是顯示了模型的靜態結構，特別是模型中存在的類、類的內部結構以及它們與其他類的關系等，類圖不顯示暫時性的資訊，類圖是面向物件建模的主要組成部分，

2.2 類圖的作用

在軟體工程中，類圖是一種靜態的結構圖，描述了系統的類的集合，類的屬性和類之間的關系，可以簡化了人們對系統的理解；
類圖是系統分析和設計階段的重要產物，是系統編碼和測驗的重要模型，

2.3 類圖表示法

2.3.1 類的表示方式

在UML類圖中，類使用包含類名、屬性(field) 和方法(method) 且帶有分割線的矩形來表示，比如下圖表示一個Employee類，它包含name,age和address這3個屬性，以及work()方法，

屬性/方法名稱前加的加號和減號表示了這個屬性/方法的可見性，UML類圖中表示可見性的符號有三種：

+：表示public
-：表示private
：表示protected

屬性的完整表示方式是： 可見性名稱：型別 [ = 預設值]

方法的完整表示方式是： 可見性名稱(引數串列) [ ：回傳型別]

注意：

? 1，中括號中的內容表示是可選的

? 2，也有將型別放在變數名前面，回傳值型別放在方法名前面

舉個栗子：

上圖Demo類定義了三個方法：

method()方法：修飾符為public，沒有引數，沒有回傳值，
method1()方法：修飾符為private，沒有引數，回傳值型別為String，
method2()方法：修飾符為protected，接收兩個引數，第一個引數型別為int，第二個引數型別為String，回傳值型別是int，

2.3.2 類與類之間關系的表示方式

2.3.2.1 關聯關系

關聯關系是物件之間的一種參考關系，用于表示一類物件與另一類物件之間的聯系，如老師和學生、師傅和徒弟、丈夫和妻子等，關聯關系是類與類之間最常用的一種關系，分為一般關聯關系、聚合關系和組合關系，我們先介紹一般關聯，

關聯又可以分為單向關聯，雙向關聯，自關聯，

1，單向關聯

在UML類圖中單向關聯用一個帶箭頭的實線表示，上圖表示每個顧客都有一個地址，這通過讓Customer類持有一個型別為Address的成員變數類實作，

2，雙向關聯

從上圖中我們很容易看出，所謂的雙向關聯就是雙方各自持有對方型別的成員變數，

在UML類圖中，雙向關聯用一個不帶箭頭的直線表示，上圖中在Customer類中維護一個List<Product>，表示一個顧客可以購買多個商品；在Product類中維護一個Customer型別的成員變數表示這個產品被哪個顧客所購買，

3，自關聯

自關聯在UML類圖中用一個帶有箭頭且指向自身的線表示，上圖的意思就是Node類包含型別為Node的成員變數，也就是“自己包含自己”，

2.3.2.2 聚合關系

聚合關系是關聯關系的一種，是強關聯關系，是整體和部分之間的關系，

聚合關系也是通過成員物件來實作的，其中成員物件是整體物件的一部分，但是成員物件可以脫離整體物件而獨立存在，例如，學校與老師的關系，學校包含老師，但如果學校停辦了，老師依然存在，

在 UML 類圖中，聚合關系可以用帶空心菱形的實線來表示，菱形指向整體，下圖所示是大學和教師的關系圖：

2.3.2.3 組合關系

組合表示類之間的整體與部分的關系，但它是一種更強烈的聚合關系，

在組合關系中，整體物件可以控制部分物件的生命周期，一旦整體物件不存在，部分物件也將不存在，部分物件不能脫離整體物件而存在，例如，頭和嘴的關系，沒有了頭，嘴也就不存在了，

在 UML 類圖中，組合關系用帶實心菱形的實線來表示，菱形指向整體，下圖所示是頭和嘴的關系圖：

2.3.2.4 依賴關系

依賴關系是一種使用關系，它是物件之間耦合度最弱的一種關聯方式，是臨時性的關聯，在代碼中，某個類的方法通過區域變數、方法的引數或者對靜態方法的呼叫來訪問另一個類（被依賴類）中的某些方法來完成一些職責，

在 UML 類圖中，依賴關系使用帶箭頭的虛線來表示，箭頭從使用類指向被依賴的類，下圖所示是司機和汽車的關系圖，司機駕駛汽車：

2.3.2.5 繼承關系

繼承關系是物件之間耦合度最大的一種關系，表示一般與特殊的關系，是父類與子類之間的關系，是一種繼承關系，

在 UML 類圖中，泛化關系用帶空心三角箭頭的實線來表示，箭頭從子類指向父類，在代碼實作時，使用面向物件的繼承機制來實作泛化關系，例如，Student 類和 Teacher 類都是 Person 類的子類，其類圖如下圖所示：

2.3.2.6 實作關系

實作關系是介面與實作類之間的關系，在這種關系中，類實作了介面，類中的操作實作了介面中所宣告的所有的抽象操作，

在 UML 類圖中，實作關系使用帶空心三角箭頭的虛線來表示，箭頭從實作類指向介面，例如，汽車和船實作了交通工具，其類圖如圖 9 所示，

3，軟體設計原則

在軟體開發中，為了提高軟體系統的可維護性和可復用性，增加軟體的可擴展性和靈活性，程式員要盡量根據6條原則來開發程式，從而提高軟體開發效率、節約軟體開發成本和維護成本，

3.1 開閉原則

對擴展開放，對修改關閉，在程式需要進行拓展的時候，不能去修改原有的代碼，實作一個熱插拔的效果，簡言之，是為了使程式的擴展性好，易于維護和升級，

想要達到這樣的效果，我們需要使用介面和抽象類，

因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟體架構的穩定，而軟體中易變的細節可以從抽象派生來的實作類來進行擴展，當軟體需要發生變化時，只需要根據需求重新派生一個實作類來擴展就可以了，

下面以 搜狗輸入法 的皮膚為例介紹開閉原則的應用，

【例】搜狗輸入法 的皮膚設計，

分析：搜狗輸入法 的皮膚是輸入法背景圖片、視窗顏色和聲音等元素的組合，用戶可以根據自己的喜愛更換自己的輸入法的皮膚，也可以從網上下載新的皮膚，這些皮膚有共同的特點，可以為其定義一個抽象類（AbstractSkin），而每個具體的皮膚（DefaultSpecificSkin和HeimaSpecificSkin）是其子類，用戶表單可以根據需要選擇或者增加新的主題，而不需要修改原代碼，所以它是滿足開閉原則的，

3.2 里氏代換原則

里氏代換原則是面向物件設計的基本原則之一，

里氏代換原則：任何基類可以出現的地方，子類一定可以出現，通俗理解：子類可以擴展父類的功能，但不能改變父類原有的功能，換句話說，子類繼承父類時，除添加新的方法完成新增功能外，盡量不要重寫父類的方法，

如果通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可復用性會比較差，特別是運用多型比較頻繁時，程式運行出錯的概率會非常大，

下面看一個里氏替換原則中經典的一個例子

【例】正方形不是長方形，

在數學領域里，正方形毫無疑問是長方形，它是一個長寬相等的長方形，所以，我們開發的一個與幾何圖形相關的軟體系統，就可以順理成章的讓正方形繼承自長方形，

代碼如下：

長方形類（Rectangle）：

public class Rectangle {
    private double length;
    private double width;

    public double getLength() {
        return length;
    }

    public void setLength(double length) {
        this.length = length;
    }

    public double getWidth() {
        return width;
    }

    public void setWidth(double width) {
        this.width = width;
    }
}

正方形（Square）：

由于正方形的長和寬相同，所以在方法setLength和setWidth中，對長度和寬度都需要賦相同值，

public class Square extends Rectangle {
    
    public void setWidth(double width) {
        super.setLength(width);
        super.setWidth(width);
    }

    public void setLength(double length) {
        super.setLength(length);
        super.setWidth(length);
    }
}

類RectangleDemo是我們的軟體系統中的一個組件，它有一個resize方法依賴基類Rectangle，resize方法是RectandleDemo類中的一個方法，用來實作寬度逐漸增長的效果，

public class RectangleDemo {
    
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() <= rectangle.getLength()) {
            rectangle.setWidth(rectangle.getWidth() + 1);
        }
    }

    //列印長方形的長和寬
    public static void printLengthAndWidth(Rectangle rectangle) {
        System.out.println(rectangle.getLength());
        System.out.println(rectangle.getWidth());
    }

    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setLength(20);
        rectangle.setWidth(10);
        resize(rectangle);
        printLengthAndWidth(rectangle);

        System.out.println("============");

        Rectangle rectangle1 = new Square();
        rectangle1.setLength(10);
        resize(rectangle1);
        printLengthAndWidth(rectangle1);
    }
}

我們運行一下這段代碼就會發現，假如我們把一個普通長方形作為引數傳入resize方法，就會看到長方形寬度逐漸增長的效果，當寬度大于長度,代碼就會停止，這種行為的結果符合我們的預期；假如我們再把一個正方形作為引數傳入resize方法后，就會看到正方形的寬度和長度都在不斷增長，代碼會一直運行下去，直至系統產生溢位錯誤，所以，普通的長方形是適合這段代碼的，正方形不適合，
我們得出結論：在resize方法中，Rectangle型別的引數是不能被Square型別的引數所代替，如果進行了替換就得不到預期結果，因此，Square類和Rectangle類之間的繼承關系違反了里氏代換原則，它們之間的繼承關系不成立，正方形不是長方形，

如何改進呢？此時我們需要重新設計他們之間的關系，抽象出來一個四邊形介面(Quadrilateral)，讓Rectangle類和Square類實作Quadrilateral介面

3.3 依賴倒轉原則

高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象，簡單的說就是要求對抽象進行編程，不要對實作進行編程，這樣就降低了客戶與實作模塊間的耦合，

下面看一個例子來理解依賴倒轉原則

【例】組裝電腦

現要組裝一臺電腦，需要配件cpu，硬碟，記憶體條，只有這些配置都有了，計算機才能正常的運行，選擇cpu有很多選擇，如Intel，AMD等，硬碟可以選擇希捷，西數等，記憶體條可以選擇金士頓，海盜船等，

類圖如下：

代碼如下：

希捷硬碟類（XiJieHardDisk）:

public class XiJieHardDisk implements HardDisk {

    public void save(String data) {
        System.out.println("使用希捷硬碟存盤資料" + data);
    }

    public String get() {
        System.out.println("使用希捷希捷硬碟取資料");
        return "資料";
    }
}

Intel處理器（IntelCpu）：

public class IntelCpu implements Cpu {

    public void run() {
        System.out.println("使用Intel處理器");
    }
}

金士頓記憶體條（KingstonMemory）：

public class KingstonMemory implements Memory {

    public void save() {
        System.out.println("使用金士頓作為記憶體條");
    }
}

電腦（Computer）：

public class Computer {

    private XiJieHardDisk hardDisk;
    private IntelCpu cpu;
    private KingstonMemory memory;

    public IntelCpu getCpu() {
        return cpu;
    }

    public void setCpu(IntelCpu cpu) {
        this.cpu = cpu;
    }

    public KingstonMemory getMemory() {
        return memory;
    }

    public void setMemory(KingstonMemory memory) {
        this.memory = memory;
    }

    public XiJieHardDisk getHardDisk() {
        return hardDisk;
    }

    public void setHardDisk(XiJieHardDisk hardDisk) {
        this.hardDisk = hardDisk;
    }

    public void run() {
        System.out.println("計算機作業");
        cpu.run();
        memory.save();
        String data = https://www.cnblogs.com/codepaopao/p/hardDisk.get();
        System.out.println("從硬碟中獲取的資料為：" + data);
    }
}

測驗類（TestComputer）：

測驗類用來組裝電腦，

public class TestComputer {
    public static void main(String[] args) {
        Computer computer = new Computer();
        computer.setHardDisk(new XiJieHardDisk());
        computer.setCpu(new IntelCpu());
        computer.setMemory(new KingstonMemory());

        computer.run();
    }
}

上面代碼可以看到已經組裝了一臺電腦，但是似乎組裝的電腦的cpu只能是Intel的，記憶體條只能是金士頓的，硬碟只能是希捷的，這對用戶肯定是不友好的，用戶有了機箱肯定是想按照自己的喜好，選擇自己喜歡的配件，

根據依賴倒轉原則進行改進：

代碼我們只需要修改Computer類，讓Computer類依賴抽象（各個配件的介面），而不是依賴于各個組件具體的實作類，

類圖如下：

電腦（Computer）：

public class Computer {

    private HardDisk hardDisk;
    private Cpu cpu;
    private Memory memory;

    public HardDisk getHardDisk() {
        return hardDisk;
    }

    public void setHardDisk(HardDisk hardDisk) {
        this.hardDisk = hardDisk;
    }

    public Cpu getCpu() {
        return cpu;
    }

    public void setCpu(Cpu cpu) {
        this.cpu = cpu;
    }

    public Memory getMemory() {
        return memory;
    }

    public void setMemory(Memory memory) {
        this.memory = memory;
    }

    public void run() {
        System.out.println("計算機作業");
    }
}

面向物件的開發很好的解決了這個問題，一般情況下抽象的變化概率很小，讓用戶程式依賴于抽象，實作的細節也依賴于抽象，即使實作細節不斷變動，只要抽象不變，客戶程式就不需要變化，這大大降低了客戶程式與實作細節的耦合度，

3.4 介面隔離原則

客戶端不應該被迫依賴于它不使用的方法；一個類對另一個類的依賴應該建立在最小的介面上，

下面看一個例子來理解介面隔離原則

【例】安全門案例

我們需要創建一個黑馬品牌的安全門，該安全門具有防火、防水、防盜的功能，可以將防火，防水，防盜功能提取成一個介面，形成一套規范，類圖如下：

上面的設計我們發現了它存在的問題，黑馬品牌的安全門具有防盜，防水，防火的功能，現在如果我們還需要再創建一個傳智品牌的安全門，而該安全門只具有防盜、防水功能呢？很顯然如果實作SafetyDoor介面就違背了介面隔離原則，那么我們如何進行修改呢？看如下類圖：

代碼如下：

AntiTheft（介面）：

public interface AntiTheft {
    void antiTheft();
}

Fireproof（介面）：

public interface Fireproof {
    void fireproof();
}

Waterproof（介面）：

public interface Waterproof {
    void waterproof();
}

HeiMaSafetyDoor（類）：

public class HeiMaSafetyDoor implements AntiTheft,Fireproof,Waterproof {
    public void antiTheft() {
        System.out.println("防盜");
    }

    public void fireproof() {
        System.out.println("防火");
    }


    public void waterproof() {
        System.out.println("防水");
    }
}

ItcastSafetyDoor（類）：

public class ItcastSafetyDoor implements AntiTheft,Fireproof {
    public void antiTheft() {
        System.out.println("防盜");
    }

    public void fireproof() {
        System.out.println("防火");
    }
}

3.5 迪米特法則

迪米特法則又叫最少知識原則，

只和你的直接朋友交談，不跟“陌生人”說話（Talk only to your immediate friends and not to strangers），

其含義是：如果兩個軟體物體無須直接通信，那么就不應當發生直接的相互呼叫，可以通過第三方轉發該呼叫，其目的是降低類之間的耦合度，提高模塊的相對獨立性，

迪米特法則中的“朋友”是指：當前物件本身、當前物件的成員物件、當前物件所創建的物件、當前物件的方法引數等，這些物件同當前物件存在關聯、聚合或組合關系，可以直接訪問這些物件的方法，

下面看一個例子來理解迪米特法則

【例】明星與經紀人的關系實體

明星由于全身心投入藝術，所以許多日常事務由經紀人負責處理，如和粉絲的見面會，和媒體公司的業務洽淡等，這里的經紀人是明星的朋友，而粉絲和媒體公司是陌生人，所以適合使用迪米特法則，

類圖如下：

代碼如下：

明星類（Star）

public class Star {
    private String name;

    public Star(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

粉絲類（Fans）

public class Fans {
    private String name;

    public Fans(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

媒體公司類（Company）

public class Company {
    private String name;

    public Company(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

經紀人類（Agent）

public class Agent {
    private Star star;
    private Fans fans;
    private Company company;

    public void setStar(Star star) {
        this.star = star;
    }

    public void setFans(Fans fans) {
        this.fans = fans;
    }

    public void setCompany(Company company) {
        this.company = company;
    }

    public void meeting() {
        System.out.println(fans.getName() + "與明星" + star.getName() + "見面了，");
    }

    public void business() {
        System.out.println(company.getName() + "與明星" + star.getName() + "洽淡業務，");
    }
}

3.6 合成復用原則

合成復用原則是指：盡量先使用組合或者聚合等關聯關系來實作，其次才考慮使用繼承關系來實作，

通常類的復用分為繼承復用和合成復用兩種，

繼承復用雖然有簡單和易實作的優點，但它也存在以下缺點：

繼承復用破壞了類的封裝性，因為繼承會將父類的實作細節暴露給子類，父類對子類是透明的，所以這種復用又稱為“白箱”復用，
子類與父類的耦合度高，父類的實作的任何改變都會導致子類的實作發生變化，這不利于類的擴展與維護，
它限制了復用的靈活性，從父類繼承而來的實作是靜態的，在編譯時已經定義，所以在運行時不可能發生變化，

采用組合或聚合復用時，可以將已有物件納入新物件中，使之成為新物件的一部分，新物件可以呼叫已有物件的功能，它有以下優點：

它維持了類的封裝性，因為成分物件的內部細節是新物件看不見的，所以這種復用又稱為“黑箱”復用，
物件間的耦合度低，可以在類的成員位置宣告抽象，
復用的靈活性高，這種復用可以在運行時動態進行，新物件可以動態地參考與成分物件型別相同的物件，

下面看一個例子來理解合成復用原則

【例】汽車分類管理程式

汽車按“動力源”劃分可分為汽油汽車、電動汽車等；按“顏色”劃分可分為白色汽車、黑色汽車和紅色汽車等，如果同時考慮這兩種分類，其組合就很多，類圖如下：

從上面類圖我們可以看到使用繼承復用產生了很多子類，如果現在又有新的動力源或者新的顏色的話，就需要再定義新的類，我們試著將繼承復用改為聚合復用看一下，

其他設計模式文章：

23種設計模式之設計模式介紹（一）
23種設計模式之創建者模式（二）
23種設計模式之結構型模式（三）
23種設計模式之行為型模式（四）
23種設計模式之自定義Spring框架（五）

本文來自博客園，作者：paopaoa，轉載請注明原文鏈接：https://www.cnblogs.com/codepaopao/p/16865257.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/528856.html

標籤：設計模式

上一篇：京東云開發者｜軟體架構可視化及C4模型：架構設計不僅僅是UML

下一篇：23種設計模式之設計模式介紹（一）

23種設計模式之設計模式介紹（一）

1，設計模式概述

1.1 軟體設計模式的產生背景

1.2 軟體設計模式的概念

1.3 學習設計模式的必要性

1.4 設計模式分類

2，UML圖

2.1 類圖概述

2.2 類圖的作用

2.3 類圖表示法

2.3.1 類的表示方式

：表示protected

2.3.2 類與類之間關系的表示方式

2.3.2.1 關聯關系

2.3.2.2 聚合關系

2.3.2.3 組合關系

2.3.2.4 依賴關系

2.3.2.5 繼承關系

2.3.2.6 實作關系

3，軟體設計原則

3.1 開閉原則

3.2 里氏代換原則

3.3 依賴倒轉原則

3.4 介面隔離原則

3.5 迪米特法則

3.6 合成復用原則

其他設計模式文章：