【設計模式從入門到精通】00-設計模式簡介

阿新 • • 發佈：2021-10-16

設計模式簡介

筆記來源：尚矽谷Java設計模式（圖解+框架原始碼剖析）

設計模式簡介

設計模式簡介

1、設計模式的重要性

1）軟體工程中，設計模式（design pattern）是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案。

這個術語是由埃裡希.伽瑪（Erich Gamma）等人在1990年代從建築設計領域引入到電腦科學的

2）大廈VS簡易房

3）拿實際工作經歷來說，當一個專案開發完後，如果客戶提出增新功能，怎麼辦？

4）如果專案開發完後，原來程式設計師離職，你接手維護該專案怎麼辦？（維護性、可讀性、規範性）

5）目前程式設計師門檻越來越高，一線 IT 公司（大廠），都會問你在實際專案中使用過什麼設計模式，怎樣使用的，解決了什麼問題。

6）設計模式在軟體中哪裡？面向物件【OO】=》功能模組【設計模式 + 演算法（資料結構）】=》框架【多種設計模式】=》架構【伺服器叢集】

7）如果想成為合格軟體工程師，那就花時間來研究下設計模式是非常必要的

2、設計模式面試題

原型設計模式

1）有請使用 UML 類圖畫出原型模式核心角色
2）原型設計模式的深拷貝和淺拷貝是什麼，並寫出深拷貝的兩種方式的原始碼（重寫 clone 方法實現深拷貝、使用序列化來實現深拷貝）
3）在 Spring 框架中哪裡使用到原型模式，並對原始碼進行分析
4）Spring 中原型 bean 的建立，就是原型模式的應用
5）程式碼分析 + Debug 原始碼

設計模式七大原則

1）單一職責原則
2）介面隔離原則
3）依賴倒轉原則
4）里氏替換原則
5）開閉原則（OCP）
6）迪米特法則
7）合成複用原則

要求：

1）七大設計原則核心思想
2）能夠以類圖的說明設計原則
3）在專案實際開發中，你在哪裡使用到了 OCP 原則

狀態模式

金融借貸平臺專案：借貸平臺的訂單，有稽核-釋出-搶單等等步驟，隨著操作的不同，會改變訂單的狀態，專案中的這個模組實現就會使用到狀態模式，請你使用狀態模式進行設計，並完成實際程式碼

問題分析：這類程式碼難以應對變化，在新增一種狀態時，我們需要手動新增 if/else ，在新增一種功能時，要對所有的狀態進行判斷。因此程式碼會變得越來越臃腫，並且一旦沒有處理某個狀態，便會發生極其嚴重的BUG，難以維護

直譯器設計模式

1）介紹直譯器設計模式是什麼？
2）畫出直譯器設計模式的 UML 類圖，分析設計模式中的各個角色是什麼？
3）請說明 Spring 的框架中，哪裡使用到了直譯器設計模式，並做原始碼級別的分析

單例設計模式

單例設計模式一共有幾種實現方式？請分別用程式碼實現，並說明各個實現方式的優點和實點？

單例設計模式一共有8種寫法，後面我們會依次講到

1）餓漢式兩種
2）懶漢式三種
3）雙重檢查
4）靜態內部類
5）列舉

3、設計模式七大原則

設計模式目的

編寫軟體過程中，程式設計師面臨著來自耦合性，內聚性以及可維護性，可擴充套件性，重用性，靈活性等多方面的挑戰

設計模式是為了讓程式（軟體），具有更好的

1）可複用性（即：相同功能的程式碼，不用多次編寫，也叫做程式碼重用性）
2）可讀性（即：程式設計規範性，便於其他程式設計師的閱讀和理解）
3）可擴充套件性（即：當需要增加新的功能時，非常的方便，也叫做可維護性）
4）可靠性（即：當我們增加新的功能後，對原來的功能沒有影響）
5）使程式呈現高內聚，低耦合的特性

分享金句

設計模式包含了面向物件的精髓，“懂了設計模式，你就懂了面向物件分析和設計（OOA/D）的精要”

Scott Mavers 在其鉅著《Effective C++》就曾經說過：C++ 老手和 C++ 新手的區別就是前者手背上有很多傷疤

設計模式七大原則

設計模式原則，其實就是程式設計師在程式設計時，應當遵守的原則，也是各種設計模式的基礎（即：設計模式為什麼這樣設計的依據）設計模式

常用的七大原則有：

1）單一職責原則
2）介面隔離原則
3）依賴倒轉原則
4）里氏替換原則
5）開閉原則
6）迪米特法則
7）合成複用原則

3.1、單一職責原則（Single Responsibility Principle）

基本介紹

對類來說的，即一個類應該只負責一項職責。如類A負責兩個不同職責：職責1，職責2。當職責1需求變更而改變A時，可能造成職責2執行錯誤，所以需要將類A的粒度分解為A1，A2

應用例項

1）以交通工具案例講解

2）看老師程式碼演示

3）方案1[分析說明]

public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽車");
        vehicle.run("輪船");
        vehicle.run("飛機");
    }
}

/**
 * 方式1的分析
 * 1.在方式1的run方法中，違反了單一職責原則
 * 2.解決的方案非常的簡單，根據交通工具執行方法不同，分解成不同類即可
 */
class Vehicle{
    public void run(String type){
        if ("汽車".equals(type)) {
            System.out.println(type + "在公路上執行...");
        } else if ("輪船".equals(type)) {
            System.out.println(type + "在水面上執行...");
        } else if ("飛機".equals(type)) {
            System.out.println(type + "在天空上執行...");
        }
    }
}

4）方案2[分析說明]

public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("汽車");
        WaterVehicle waterVehicle = new WaterVehicle();
        waterVehicle.run("輪船");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飛機");
    }
}

/**
 * 方案2的分析
 * 1.遵守單一職責原則
 * 2.但是這樣做的改動很大，即將類分解，同時修改客戶端
 * 3.改進：直接修改Vehicle類，改動的程式碼會比較少=>方案3
 */
class RoadVehicle{
    public void run(String type){
        System.out.println(type + "在公路上執行...");
    }
}
class WaterVehicle{
    public void run(String type){
        System.out.println(type + "在水面上執行...");
    }
}
class AirVehicle{
    public void run(String type){
        System.out.println(type + "在天空上執行...");
    }
}

5）方案3[分析說明]

public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle = new Vehicle2();
        vehicle.run("汽車");
        vehicle.runWater("輪船");
        vehicle.runAir("飛機");
    }
}

/**
 * 方式3的分析
 * 1.這種修改方法沒有對原來的類做大的修改，只是增加方法
 * 2.這裡雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責
 */
class Vehicle2{
    public void run(String type){
        System.out.println(type + "在公路上執行...");
    }
    public void runWater(String type){
        System.out.println(type + "在水面上執行...");
    }
    public void runAir(String type){
        System.out.println(type + "在天空上執行...");
    }
}

總結

類分解，可能成本較高
解決方案：不在類級別上“單一職責”，往下沉，在方法級別上“單一職責”

注意事項和細節

1）降低類的複雜度，一個類只負責一項職責
2）提高類的可讀性，可維護性
3）降低變更引起的風險
4）通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在程式碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則

3.2、介面隔離原則（Interface Segregation Principle）

基本介紹

1）客戶端不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上
2）先看一張圖

3）類 A 通過介面 Interface1 依賴類 B，類 C 通過介面 Interface1 依賴類 D，如果介面 Interface1 對於類 A 和類 C 來說不是最小介面，那麼類 B 和類 D 必須去實現他們不需要的方法
4）按隔離原則應當這樣處理：將介面 Interface1 拆分為獨立的幾個介面，類 A 和類 C 分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則

應用例項

1）類 A 通過介面 Interface1 依賴類 B，類 C 通過介面 Interface1 依賴類 D，請編寫程式碼完成此應用例項
2）看老師程式碼

interface Interface1 {
    void operation1();

    void operation2();

    void operation3();

    void operation4();

    void operation5();
}

class B implements Interface1 {

    @Override
    public void operation1() {
        System.out.println("B 實現了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("B 實現了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("B 實現了 operation3");
    }

    @Override
    public void operation4() {
        System.out.println("B 實現了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("B 實現了 operation5");
    }
}

class D implements Interface1 {

    @Override
    public void operation1() {
        System.out.println("D 實現了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("D 實現了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("D 實現了 operation3");
    }

    @Override
    public void operation4() {
        System.out.println("D 實現了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("D 實現了 operation5");
    }
}

/**
 * A類通過介面Interface1依賴（使用）B類，但是隻會用到1，2，3方法
 */
class A {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend2(Interface1 i) {
        i.operation2();
    }

    public void depend3(Interface1 i) {
        i.operation3();
    }
}

/**
 * C類通過介面Interface1依賴（使用）D類，但是隻會用到1，4，5方法
 */
class C {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend4(Interface1 i) {
        i.operation4();
    }

    public void depend5(Interface1 i) {
        i.operation5();
    }
}

問題與改進

1）類 A 通過介面 Interface1 依賴類 B，類 C 通過介面 Interface1 依賴類 D，如果介面 Interface1 對於類 A 和類 C 來說不是最小介面，那麼類 B 和類 D 必須去實現他們不需要的方法
2）將介面 Interface1 拆分為獨立的幾個介面，類 A 和類 C 分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則
3）介面 Interface1 中出現的方法，根據實際情況拆分為三個介面
4）程式碼實現

interface Interface1 {
    void operation1();
}

interface Interface2 {
    void operation2();

    void operation3();
}

interface Interface3 {
    void operation4();

    void operation5();
}

class B implements Interface1, Interface2 {

    @Override
    public void operation1() {
        System.out.println("B 實現了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("B 實現了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("B 實現了 operation3");
    }
}

class D implements Interface1, Interface3 {

    @Override
    public void operation1() {
        System.out.println("D 實現了 operation1");
    }

    @Override
    public void operation4() {
        System.out.println("D 實現了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("D 實現了 operation5");
    }
}

/**
 * A類通過介面Interface1,Interface2依賴（使用）B類，但是隻會用到1，2，3方法
 */
class A {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend2(Interface2 i) {
        i.operation2();
    }

    public void depend3(Interface2 i) {
        i.operation3();
    }
}

/**
 * C類通過介面Interface1,Interface3依賴（使用）D類，但是隻會用到1，4，5方法
 */
class C {
    public void depend1(Interface1 i) {
        i.operation1();
    }

    public void depend4(Interface3 i) {
        i.operation4();
    }

    public void depend5(Interface3 i) {
        i.operation5();
    }
}

3.3、依賴倒轉原則（Dependence Inversion Principle）

基本介紹

1）高層模組不應該依賴低層模組，二者都應該依賴其抽象
2）抽象不應該依賴細節，細節應該依賴抽象
3）依賴倒轉（倒置）的中心思想是面向介面程式設計
4）依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在java中，抽象指的是介面或抽象類，細節就是具體的實現類
5）使用介面或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成

應用例項

1）請程式設計完成 Person 接收訊息的功能

2）實現方案 1 + 分析說明

/**
 * 方式1分析
 * 1.簡單，比較容易想到
 * 2.如果我們獲取的物件是微信，簡訊等等，則新增類，同時 Peron也要增加相應的接收方法
 * 3.解決思路：
 * 引入一個抽象的介面IReceiver，表示接收者，這樣Person類與介面IReceiver發生依賴
 * 因為Email，Weixin等等屬於接收的範圍，他們各自實現IReceiver介面就ok，這樣我們就符號依賴倒轉原則
 */
class Email {
    public String getInfo() {
        return "電子郵件資訊：Hello World！";
    }
}

class Person {
    public void receive(Email email) {
        System.out.println(email.getInfo());
    }
}

3）實現方案 2 + 分析說明

interface IReceiver {
    String getInfo();
}

class Email implements IReceiver {
    @Override
    public String getInfo() {
        return "電子郵件資訊：Hello World！";
    }
}

class Weixin implements IReceiver {
    @Override
    public String getInfo() {
        return "微信訊息：Hello World！";
    }
}

class ShortMessage implements IReceiver {
    @Override
    public String getInfo() {
        return "簡訊資訊：Hello World！";
    }
}

class Person {
    public void receive(IReceiver receiver) {
        System.out.println(receiver.getInfo());
    }
}

依賴關係傳遞的三種方式

1）介面傳遞

//方式1：通過介面傳遞實現依賴
//開關的介面
interface IOpenAndClose {
    void open(ITV tv);//抽象方法，接收介面
}
//ITV介面
interface ITV {
    void play();
}
//實現介面
class OpenAndClose implements IOpenAndClose {
    public void open(ITV tv){
        tv.play();
    }
}

2）構造方法傳遞

//方式2：通過建構函式實現依賴
//開關的介面
interface IOpenAndClose {
    void open();//抽象方法
}
//ITV介面
interface ITV {
    public void play();
}
//實現介面
class OpenAndClose implements IOpenAndClose {
    private ITV tv; // 成員
    
    public OpenAndClose(ITV tv){ // 構造器
        this.tv = tv;
    }
    
    public void open(){
        this.tv.play();
    }
}

3）setter 方式傳遞

//方式3，通過setter方法傳遞
interface IOpenAndClose{
    void open();//抽象方法
    void setTv(ITV tv);
}
//ITV介面
interface ITV{
    void play();
}
//實現介面
class OpenAndClose implements IOpenAndClose{
    private ITV tv;
    public void setTv(ITV tv){
        this.tv=tv;
    }
    public void open(){
        this.tv.play();
    }
}

注意事項和細節

1）低層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好
2）變數的宣告型別儘量是抽象類或介面，這樣我們的變數引用和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化
3）繼承時遵循里氏替換原則

3.4、里氏替換原則（Liskov Substitution Principle）

OO 中繼承性的思考和說明

1）繼承包含這樣一層含義：父類中凡是已經實現好的方法，實際上是在設定規範和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞
2）繼承在給程式設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能產生故障
3）問題提出：在程式設計中，如何正確使用繼承？=>里氏替換原則

基本介紹

1）里氏替換原則在1988年，由麻省理工學院的以為姓裡的女士提出的
2）如果對每個型別為 T1 的物件 o1，都有型別為 T2 的物件 o2，使得以 T1 定義的所有程式 P 在所有的物件 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。換句話說，所有引用基類的地方必須能透明地使用其子類的物件
3）在使用繼承時，遵循里氏替換原則，在子類中儘量不要重寫父類的方法
4）里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可以通過聚合、組合、依賴來解決問題

一個程式引出的問題和思考

先看個程式，思考下問題和解決思路

public void test() {
    A a = new A();
    System.out.println("11-3=" + a.func1(11, 3));
    System.out.println("1-8=" + a.func1(1, 8));
    System.out.println("---------------------");

    B b = new B();
    System.out.println("11-3=" + b.func1(11, 3));
    System.out.println("1-8=" + b.func1(1, 8));
    System.out.println("11+3+9=" + b.func2(11, 3));
}

class A {
    //返回兩個數的差
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

class B extends A {
    @Override
    public int func1(int num1, int num2) {
        return num1 + num2;
    }

    //增加了一個新功能：完成兩個數相加，然後和9求和
    public int func2(int num1, int num2) {
        return func1(num1, num2) + 9;
    }
}

解決方法

1）我們發現原來執行正常的相減功能發生了錯誤。原因就是類 B 無意中重寫了父類的方法，造成原有功能出現錯誤。在實際程式設計中，我們常常會通過重寫父類的方法完成新的功能，這樣寫起來雖然簡單，但整個繼承體系的複用性會比較差。特別是執行多型比較頻繁的時候

2）通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合、組合等關係代替

3）改進方案

//建立一個更加基礎的基類
class Base {
    //將更基礎的成員和方法寫到Base類中
}

class A extends Base {
    //返回兩個數的差
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

class B extends Base {
    //如果B需要使用A類的方法，使用組合關係
    private A a;

    public int func1(int num1, int num2) {
        return num1 + num2;
    }

    //增加了一個新功能：完成兩個數相加，然後和9求和
    public int func2(int num1, int num2) {
        return func1(num1, num2) + 9;
    }

    public int func3(int num1, int num2) {
        return this.a.func1(num1, num2);
    }
}

3.5、開閉原則（Open Closed Principle）

基本介紹

1）開閉原則是程式設計中最基礎、最重要的設計原則
2）一個軟體實體如類、模組和函式應該對擴充套件開放（對提供者而言），對修改關閉（對使用者而言）。用抽象構建框架，用實現擴充套件細節
3）當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化
4）程式設計中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則

看一段程式碼

一個畫圖形的功能，類圖設計如下：

class GraphicEditor {
    public void drawShape(Shape s) {
        if (s.m_type == 1) {
            drawRectangle(s);
        } else if (s.m_type == 2) {
            drawCircle(s);

        } else if (s.m_type == 3) {
            drawTriangle(s);
        }
    }

    public void drawRectangle(Shape r) {
        System.out.println("矩形");
    }

    public void drawCircle(Shape r) {
        System.out.println("圓形");
    }

    public void drawTriangle(Shape r) {
        System.out.println("三角形");
    }
}

class Shape {
    public int m_type;
}

class RectangleShape extends Shape {
    RectangleShape() {
        m_type = 1;
    }
}

class CircleShape extends Shape {
    CircleShape() {
        m_type = 2;
    }
}

class TriangleShape extends Shape {
    TriangleShape() {
        m_type = 3;
    }
}

方式 1 的優缺點

1）優點是比較好理解，簡單易操作
2）缺點是違反了設計模式的 OCP 原則，即對擴充套件開放（提供方），對修改關閉（使用方）。即當我們給類增加新功能的時喉，儘量不修改程式碼，或者儘可能少修改程式碼
3）比如我們這時要新增加一個圖形種類，我們需要做如下修改，修改的地方較多4）程式碼演示

方式 1 的改進的思路分析

把建立 Shape 類做成抽象類，並提供一個抽象的 draw 方法，讓子類去實現即可

這樣我們有新的圖形種類時，只需要讓新的圖形類繼承 Shape，並實現 draw 方法即可

使用方的程式碼就不需要修改，滿足了開閉原則

方式 2 來解決

1）方式 2 的設計方案：定義一個 Shape 抽象類

2）看程式碼示例

class GraphicEditor {
    public void drawShape(Shape s) {
        s.draw();
    }
}

abstract class Shape {
    int m_type;

    public abstract void draw();
}

class RectangleShape extends Shape {
    RectangleShape() {
        m_type = 1;
    }

    @Override
    public void draw() {
        System.out.println("矩形");
    }
}

class CircleShape extends Shape {
    CircleShape() {
        m_type = 2;
    }

    @Override
    public void draw() {
        System.out.println("圓形");
    }
}

class TriangleShape extends Shape {
    TriangleShape() {
        m_type = 3;
    }

    @Override
    public void draw() {
        System.out.println("三角形");
    }
}

3）從方式 2 看，程式碼滿足了 OCP 原則

3.6、迪米特法則（Demeter Principle）

基本介紹

1）一個物件應該對其他物件保持最少的瞭解
2）類與類關係越密切，耦合度越大
3）迪米特法則又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外洩露任何資訊
4）迪米特法則還有個更簡單的定義：只與直接的朋友通訊
5）直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多：依賴、關聯、組合、聚合等。其中，我們稱出現成員變數，方法引數，方法返回值中的類為直接的朋友，而出現在區域性變數中的類不是直接的朋友。也就是說，陌生的類最好不要以區域性變數的形式出現在類的內部

應用例項

1）有一個學校，下屬有各個學院和總部，現要求打印出學校總部員工 ID 和學院員工的 id

2）程式設計實現上面的功能，看程式碼演示

//總部員工
class Employee {
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

//學院員工
class CollegeEmployee {
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

//學院員工管理 類
class CollegeManager {
    public List<CollegeEmployee> getAllEmployee() {
        List<CollegeEmployee> list = new ArrayList<>();
        CollegeEmployee collegeEmployee;
        for (int i = 0; i < 10; i++) {
            collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId("學院員工id=" + i);
            list.add(collegeEmployee);
        }
        return list;
    }
}

//總部員工管理類
class SchoolManager {
    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<>();
        Employee employee;
        for (int i = 0; i < 5; i++) {
            employee = new Employee();
            employee.setId("總部員工id=" + i);
            list.add(employee);
        }
        return list;
    }

    public void printAllEmployee(CollegeManager sub) {
        System.out.println("--------------學院員工--------------");
        List<CollegeEmployee> list1 = sub.getAllEmployee();
        for (CollegeEmployee collegeEmployee : list1) {
            System.out.println(collegeEmployee.getId());
        }
        System.out.println("---------------總部員工-------------");
        List<Employee> list2 = this.getAllEmployee();
        for (Employee employee : list2) {
            System.out.println(employee.getId());
        }
    }
}

應用例項改進

1）前面設計的問題在於 SchoolManager 中，CollegeEmployee 類並不是 SchoolManager 類的直接朋友（分析）
2）按照迪米特法則，應該避免類中出現這樣非直接朋友關係的耦合
3）對程式碼按照迪米特法則進行改進（看老師演示）

注意事項和細節

1）迪米特法則的核心是降低類之間的耦合
2）但是注意：由於每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間（物件間）耦合關係，並不是要求完全沒有依賴關係

3.7、合成複用原則（Composite Reuse Principle）

基本介紹

原則是儘量使用合成/聚合的方式，而不是使用繼承

設計原則核心思想

1）找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的程式碼混在一起
2）針對介面程式設計，而不是針對實現程式設計
3）為了互動物件之間的鬆耦合設計而努力

4、UML 類圖

UML 基本介紹

1）UML—-Unified modeling language UML（統一建模語言），是一種用於軟體系統分析和設計的語言工具，它用於幫助軟體開發人員進行思考和記錄思路的結果
2）UML 本身是一套符號的規定，就像數學符號和化學符號一樣，這些符號用於描述軟體模型中的各個元素和他們之間的關係，比如類、介面、實現、泛化、依賴、組合、聚合等

3）使用 UML 來建模，常用的工具有 Rational Rose，也可以使用一些外掛來建模

UML 圖

畫 UML 圖與寫文章差不多，都是把自己的思想描述給別人看，關鍵在於思路和條理，UML圖分類：

1）用例圖（use case）
2）靜態結構圖：類圖、物件圖、包圖、元件圖、部署圖
3）動態行為圖：互動圖（時序圖與協作圖）、狀態圖、活動圖

說明

1）類圖是描述類與類之間的關係的，是 UML 圖中最核心的
2）在講解設計模式時，我們必然會使用類圖，為了讓學員們能夠把設計模式學到位，需要先給大家講解類圖
3）溫馨提示：如果已經掌握 UML 類圖的學員，可以直接聽設計模式的章節

UML 類圖

1）用於描述系統中的類（物件）本身的組成和類（物件）之間的各種靜態關係
2）類之間的關係：依賴、泛化（繼承）、實現、關聯、聚合與組合
3）類圖簡單舉例

public class Person {
    private Integer id;
    private String name;
    public void setName(String name){
        this.name = name;
    }
    public String getName(){
        return name;
    }
}

4.1、類圖——依賴（dependence）

只要是在類中用到了對方，那麼他們之間就存在依賴關係。如果沒有對方，連編譯都通過不了

public class PersonServiceBean {
    // 類的成員屬性
    private PersonDao personDao;

    // 方法接收的引數型別
    public void save(Person person) {
    }

    // 方法的返回型別
    public IDCard getIDCard(Integer personid) {
        return null;
    }

    // 方法中使用到
    public void modify() {
        Department department = new Department();
    }

}

UML 類圖

小結

1）類中用到了對方
2）類的成員屬性
3）方法的返回型別
4）方法接收的引數型別
5）方法中使用到

4.2、類圖——泛化（Generalization）

泛化關係實際上就是繼承關係，它是依賴關係的特例

public abstract class DaoSupport {
    public void save(Object entity) {
    }

    public void delete(Object id) {
    }
}
public class PersonServiceBean extends DaoSupport {
}

UML 類圖

小結

1）泛化關係實際上就是繼承關係
2）如果 A 類繼承了 B 類，我們就說 A 和 B 存在泛化關係

4.3、類圖——實現（Implementation）

實現關係實際上就是 A 類實現 B 類，它是依賴關係的特例

public interface PersonService {
    void delete(Integer id);
}
public class PersonServiceBean implements PersonService {
    @Override
    public void delete(Integer id) {
        System.out.println("delete...");
    }
}

UML 類圖

4.4、類圖——關聯（Association）

關聯關係實際上就是類與類之間的聯絡，它是依賴關係的特例

關聯具有導航性：即雙向關係或單向關係
關係具有多重性：如“1”（表示有且僅有一個），“0...”（表示0個或者多個），“0，1”（表示0個或者一個），“n...m”（表示n到m個都可以），“m...*”（表示至少m個）

單向一對一關係

public class Person {
	private IDCard card;
}
public class IDCard {}

UML 類圖

雙向一對一關係

public class Person {
	private IDCard card;
}
public class IDCard {
	private Person person;
}

UML 類圖

4.5、類圖——聚合（Aggregation）

聚合關係表示的是整體和部分的關係，整體與部分可以分開。聚合關係是關聯關係的特例，所以它具有關聯的導航性與多重性

如：一臺電腦由鍵盤（keyboard）、顯示器（monitor），滑鼠等組成；組成電腦的各個配件是可以從電腦上分離出來的，使用帶空心菱形的實線來表示：

public class Mouse {}
public class Monitor {}
public class Computer {
    private Mouse mouse;
    private Monitor monitor;

    public void setMouse(Mouse mouse) {
        this.mouse = mouse;
    }

    public void setMonitor(Monitor monitor) {
        this.monitor = monitor;
    }
}

UML 類圖

4.6、類圖——組合（Composition）

組合關係也是整體與部分的關係，但是整體與部分不可以分開

如果我們認為 Mouse、Monitor 和 Computer 是不可分離的，則升級為組合關係

public class Mouse {}
public class Monitor {}
public class Computer {
    private Mouse mouse = new Mouse();
    private Monitor monitor = new Monitor();
}

UML 類圖

再看一個案例，在程式中我們定義實體：Person 與 IDCard、Head，那麼 Head 和 Person 就是組合，IDCard 和 Person 就是聚合

public class IDCard{}
public class Head{}
public class Person{
    private IDCard card;
    private Head head = new Head();
}

UML 類圖

但是如果在程式中，Person 實體中定義了對 IDCard 進行級聯刪除，即刪除 Person 時連同 IDCard 一起刪除，那麼 IDCard 和 Person 就是組合了

5、設計模式概述和分類

5.1、設計模式層次

1）第1層：剛開始學程式設計不久，聽說過什麼是設計模式
2）第2層：有很長時間的程式設計經驗，自己寫了很多程式碼，其中用到了設計模式，但是自己卻不知道
3）第3層：學習過了設計模式，發現自己已經在使用了，並且發現了一些新的模式挺好用的
4）第4層：閱讀了很多別人寫的原始碼和框架，在其中看到別人設計模式，並且能夠領會設計模式的精妙和帶來的好處
5）第5層：程式碼寫著寫著，自己都沒有意識到使用了設計模式，並且熟練的寫了出來

5.2、設計模式介紹

1）設計模式是程式設計師在面對同類軟體工程設計問題所總結出來的有用的經驗。模式不是程式碼，而是某類問題的通用解決方案，設計模式（Design pattern）代表了最佳實踐。這些解決方案是眾多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的
2）設計模式的本質提高軟體的維護性、通用性和擴充套件性，並降低軟體的複雜度
3）《設計模式》是經典的書，作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides Design（俗稱“四人組GOF”）
4）設計模式並不侷限於某種語言，Java、PHP、C++ 都有設計模式

5.3、設計模式型別

設計模式分為至種類型，共 23 種

1）建立型模式：單例模式、抽象工廠模式、原型模式、建造者模式、工廠模式
2）結構型模式：介面卡模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式
3）行為型模式：模版方法模式、命令模式、訪問者模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、直譯器模式（Interpreter 模式）、狀態模式、策略模式、職責鏈模式（責任鏈模式）

注意：不同的書籍上對分類和名稱略有差別

【設計模式從入門到精通】00-設計模式簡介

設計模式簡介

1、設計模式的重要性

2、設計模式面試題

3、設計模式七大原則

設計模式目的

設計模式七大原則

3.1、單一職責原則（Single Responsibility Principle）

3.2、介面隔離原則（Interface Segregation Principle）

3.3、依賴倒轉原則（Dependence Inversion Principle）

依賴關係傳遞的三種方式

3.4、里氏替換原則（Liskov Substitution Principle）

3.5、開閉原則（Open Closed Principle）

3.6、迪米特法則（Demeter Principle）

3.7、合成複用原則（Composite Reuse Principle）

設計原則核心思想

4、UML 類圖

UML 基本介紹

UML 圖

UML 類圖

4.1、類圖——依賴（dependence）

4.2、類圖——泛化（Generalization）

4.3、類圖——實現（Implementation）

4.4、類圖——關聯（Association）

單向一對一關係

雙向一對一關係

4.5、類圖——聚合（Aggregation）

4.6、類圖——組合（Composition）

5、設計模式概述和分類

5.1、設計模式層次

5.2、設計模式介紹

5.3、設計模式型別

相關推薦