2. 程式人生 > >設計模式 - 七大設計原則（三）- 迪米特法則與里氏替換原則

設計模式 - 七大設計原則（三）- 迪米特法則與里氏替換原則

阿新 • • 發佈：2019-09-26

概述

簡單介紹一下七大設計原則：

  1. 開閉原則：是所有面向物件設計的核心，對擴充套件開放，對修改關閉
  2. 依賴倒置原則：針對介面程式設計，依賴於抽象而不依賴於具體
  3. 單一職責原則：一個介面只負責一件事情，只能有一個原因導致類變化
  4. 介面隔離原則：使用多個專門的介面，而不是使用一個總介面
  5. 迪米特法則（最少知道原則）：只和朋友交流（成員變數、方法輸入輸出引數），不和陌生人說話，控制好訪問修飾符
  6. 里氏替換原則：子類可以擴充套件父類的功能，但不能改變父類原有的功能
  7. 合成複用原則：儘量使用物件組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟體複用的目的

迪米特法則

定義

迪米特原則(Law of Demeter LoD)是指一個物件應該對其他物件保持最少的瞭解，又 叫最少知道原則(Least Knowledge Principle,LKP)，儘量降低類與類之間的耦合。

迪米特原則主要強調只和朋友交流，不和陌生人說話。出現在成員變數、方法的輸入、輸 出引數中的類都可以稱之為成員朋友類，而出現在方法體內部的類不屬於朋友類。

示例

現在來設計一個許可權系統，Boss 需要檢視目前釋出到線上的課程數量。這時候，Boss 要找到 TeamLeader 去進行統計，TeamLeader 再把統計結果告訴 Boss。接下來我們還 是來看程式碼:

Course類：

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:17
 */
public class Course {
}

TeamLeader 類：

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:17
 */
public class TeamLeader {
    public void checkNumberOfCourses(List<Course> courseList) {
        System.out.println("目前已釋出的課程數量是:" + courseList.size());
    }
}

Boss 類：

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:17
 */
public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader) {
        //模擬 Boss 一頁一頁往下翻頁，TeamLeader 實時統計
        List<Course> courseList = new ArrayList<Course>();
        for (int i = 0; i < 20; i++) {
            courseList.add(new Course());
        }
        teamLeader.checkNumberOfCourses(courseList);
    }
}

測試程式碼：

public static void main(String[] args) {
    Boss boss = new Boss();
    TeamLeader teamLeader = new TeamLeader();
    boss.commandCheckNumber(teamLeader);
}

寫到這裡，其實功能已經都已經實現，程式碼看上去也沒什麼問題。根據迪米特原則，Boss 只想要結果，不需要跟 Course 產生直接的交流。而 TeamLeader 統計需要引用 Course 物件。Boss 和 Course 並不是朋友，從下面的類圖就可以看出來:

下面來對程式碼進行改造:
TeamLeader類：

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:17
 */
public class TeamLeader {
    public void checkNumberOfCourses() {
        List<Course> courseList = new ArrayList<Course>();
        for (int i = 0; i < 20; i++) {
            courseList.add(new Course());
        }
        System.out.println("目前已釋出的課程數量是:" + courseList.size());
    }
}

Boss 類：

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:17
 */
public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader) {
        teamLeader.checkNumberOfCourses();
    }
}

再來看下面的類圖，Course 和 Boss 已經沒有關聯了。

學習軟體設計原則，千萬不能形成強迫症。碰到業務複雜的場景，我們需要隨機應變。

里氏替換原則

定義

里氏替換原則(Liskov Substitution Principle,LSP)是指如果對每一個型別為 T1 的對 象 o1,都有型別為 T2 的物件 o2,使得以 T1 定義的所有程式 P 在所有的物件 o1 都替換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。

定義看上去還是比較抽象，我們重新理解一下，可以理解為一個軟體實體如果適用一個 父類的話，那一定是適用於其子類，所有引用父類的地方必須能透明地使用其子類的物件，子類物件能夠替換父類物件，而程式邏輯不變。根據這個理解，我們總結一下:

引申含義：子類可以擴充套件父類的功能，但不能改變父類原有的功能。

  1. 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
  2. 子類中可以增加自己特有的方法。
  3. 當子類的方法過載父類的方法時，方法的前置條件(即方法的輸入/入參)要比父類 方法的輸入引數更寬鬆。
  4. 當子類的方法實現父類的方法時(重寫/過載或實現抽象方法)，方法的後置條件(即 方法的輸出/返回值)要比父類更嚴格或相等。

示例

在前面講開閉原則的時候埋下了一個伏筆，我們記得在獲取折後時重寫覆蓋了父類的 getPrice()方法，增加了一個獲取原價格的方法 getOriginPrice()，顯然就違背了里氏替換 原則。我們修改一下程式碼，不應該覆蓋 getPrice()方法，增加 getDiscountPrice()方法:

/**
 * @author eamon.zhang
 * @date 2019-09-25 上午10:36
 */
public class NovelDiscountBook extends NovelBook {
    public NovelDiscountBook(String name, int price, String author) {
        super(name, price, author);
    }

    public double getDiscountPrice(){
        return super.getPrice() * 0.85;
    }
}

使用里氏替換原則有以下優點:

  1. 約束繼承氾濫，開閉原則的一種體現。
  2. 加強程式的健壯性，同時變更時也可以做到非常好的相容性，提高程式的維護性、擴 展性。降低需求變更時引入的風險。

現在來描述一個經典的業務場景，用正方形、矩形和四邊形的關係說明裡氏替換原則， 我們都知道正方形是一個特殊的長方形，那麼就可以建立一個長方形父類 Rectangle 類:

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:59
 */
public class Rectangle {
    private long height;
    private long width;

    public long getHeight() {
        return height;
    }

    public void setHeight(long height) {
        this.height = height;
    }

    public long getWidth() {
        return width;
    }

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

建立正方形 Square 類繼承長方形:

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午10:01
 */
public class Square extends Rectangle {
    private long length;

    public long getLength() {
        return length;
    }

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

    @Override
    public long getHeight() {
        return super.getHeight();
    }

    @Override
    public void setHeight(long height) {
        super.setHeight(height);
    }

    @Override
    public long getWidth() {
        return super.getWidth();
    }

    @Override
    public void setWidth(long width) {
        super.setWidth(width);
    }
}

在測試類中建立 resize()方法，根據邏輯長方形的寬應該大於等於高，我們讓高一直自增， 知道高等於寬變成正方形:

 public static void resize(Rectangle rectangle) {
    while (rectangle.getWidth() >= rectangle.getHeight()) {
        rectangle.setHeight(rectangle.getHeight() + 1);
        System.out.println("width:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
    }
    System.out.println("resize 方法結束" +
            "\nwidth:" + rectangle.getWidth() + ",height:" + rectangle.getHeight());
}

測試程式碼:

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

執行結果:

發現高比寬還大了，在長方形中是一種非常正常的情況。現在我們再來看下面的程式碼， 把長方形 Rectangle 替換成它的子類正方形 Square，修改測試程式碼:

public static void main(String[] args) {
    Square square = new Square();
    square.setLength(10);
    resize(square);
}

這時候我們執行的時候就出現了死迴圈，違背了里氏替換原則，將父類替換為子類後， 程式執行結果沒有達到預期。因此，我們的程式碼設計是存在一定風險的。里氏替換原則 只存在父類與子類之間，約束繼承氾濫。我們再來建立一個基於長方形與正方形共同的 抽象四邊形 Quadrangle 介面:

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午10:12
 */
public interface Quadrangle {
    long getWidth();

    long getHeight();
}

修改長方形 Rectangle 類:

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午9:59
 */
public class Rectangle implements Quadrangle {
    private long height;
    private long width;

    @Override
    public long getWidth() {
        return width;
    }

    public long getHeight() {
        return height;
    }

    public void setHeight(long height) {
        this.height = height;
    }

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

修改正方形類 Square 類:

/**
 * @author eamon.zhang
 * @date 2019-09-26 上午10:01
 */
public class Square implements Quadrangle {
    private long length;

    public long getLength() {
        return length;
    }

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

    @Override
    public long getWidth() {
        return length;
    }

    @Override
    public long getHeight() {
        return length;
    }
}

此時，如果我們把 resize()方法的引數換成四邊形 Quadrangle 類，方法內部就會報錯。

因為正方形 Square 已經沒有了 setWidth()和 setHeight()方法了。因此，為了約束繼承 氾濫，resize()的方法引數只能用 Rectangle 長方形。當然，我們在後面的設計模式系列文章中 中還會繼續深入講解

相關推薦

設計模式 - 七大設計原則（三）- 迪米特法則與里氏替換原則

概述 簡單介紹一下七大設計原則： 開閉原則：是所有面向物件設計的核心，對擴充套件開放，對修改關閉 依賴倒置原則：針對介面程式設計，依賴於抽象而不依賴於具體 單一職責原則：一個介面只負責一件事情，只能有一個原因導致類變化 介面隔離原則：使用多個專門的介面，而不是使用一個總介面 迪米特法則（最少知道原則）：

設計模式（九）迪米特法則

迪米特法則（LoD），也叫最少知識原則：如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫。  迪米特法則首先強調的前提是在類的結構設計上，每一個類都應當儘量降低成員的訪問許可權

設計模式簡單小例子（三）行為型模式

終於，把設計模式小例子敲完了..... 原始碼已經上傳到了GitHub. https://github.com/tanglonghui/DesignPatterns 設計模式簡單小例子（一） 建立型模式： https://blog.csdn.net/qq_40687864/artic

《設計模式——java版》（三）

三、抽象工廠模式         1.為建立一組相關或相互依賴的物件提供一個介面，而且無須指定它們的具體類。抽象工廠模式是工廠方法模式的升級版本。在有多個業務品種、業務分類時，通過抽象工廠模式產生需要的物件是一種非常好的解決方式。   &

設計模式六大原則（5）：迪米特法則

定義：一個物件應該對其他物件保持最少的瞭解。 問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。 解決方案：儘量降低類與類之間的耦合。          自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則：低耦合，高內聚。

基本設計模式學習筆記：（一）常見的七種面向物件設計原則

0.概述      面向物件設計原則為支援可維護性複用而誕生，這些原則蘊含在很多設計模式中，他們是從許多設計方案中總結出來的指導性原則1.單一原則     一個類只負責一個功能領域中的相應職責，或者說：就一個類而言，應該只有一個引起它變化的原因。個人總結：將不同職責的方法放在

六大設計原則（三）DIP依賴倒置原則

型號 pre 面向接口 alt archive 但是 松耦合 實際類型 我們 原文：六大設計原則（三）DIP依賴倒置原則 依賴倒置原則DIP（Dependence Inversion Principle） 依賴倒置原則的含義 高層模塊不能依賴低層模塊，二者都應該依賴其抽象

【轉載】設計模式_模板方法（學習）

res bootstrap 重載方法 dex col 算法實現 選擇性 parent abstract 模板方法模式，一般是為了統一子類的算法實現步驟，所使用的一種手段或者說是方式。它在父類中定義一系列算法的步驟，而將具體的實現都推遲到子類。 通常情況下，模板方法模式用

設計模式之問題集錦（一）

是把 後繼 ogr data- 跟著 沒有 解釋器 space 基本實現 設計模式的主要資料是《大話設計模式》。第一階段先看看各種模式的基本概念。實現每一個模式下的樣例。然後在進行理解性的學習和掌握，靈活掌握各種模式的長處，知道某種模式適合那種狀態。如今，樣

23種設計模式匯總整理（轉）

工廠方法 bst 基類 臨時 直接 不存在 裏氏代換原則 隔離 返回 轉自：一個小本科生的奮鬥史 感謝！ 設計模式分為三大類： 創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。 結構型模式，共七種：適配器模式、裝飾器模式、代理模

設計模式：裝飾器（Decorator）模式

讓我 分享圖片 底部 .com 一件事 輸出 PE 新的 int 設計模式：裝飾器（Decorator）模式 一、前言 裝飾器模式也是一種非常重要的模式，在Java以及程序設計中占據著重要的地位。比如Java的數據流處理，我們可能看到數據流經過不同的類的包裝和包裹，最

設計模式：觀察者（Observer）模式

image 強制轉換 trace vat PE sta obs observer -a 設計模式：觀察者（Observer）模式 一、前言 觀察者模式其實最好的名稱應該是“發布訂閱”模式，和我們現在大數據之中的發布訂閱方式比較類似，但是也有區別的地方，在上一個設計模式，

設計模式：享元（FlyWeight）模式

例子 清理 什麽 public == lean http 變量 -- 設計模式：享元（FlyWeight）模式 一、前言 享元（FlyWeight）模式顧名思義，既是輕量級的，原因就是享元，共享元素，這裏的元素指的是對象。如何共享對象，那就是在檢測對象產生的時候，如

面向對象設計原則 迪米特法則（Law of Demeter）

ast 關系 ade 描述 松耦合 系統 中介模式 dem 可能 迪米特法則（Law of Demeter） 又叫作最少知識原則（Least Knowledge Principle 簡寫LKP），英文簡寫為: LoD. 這是一種面向對象程序設計的指導原則，它描述了

第2章 面向物件的設計原則（SOLID）：5_迪米特法則

5. 迪米特法則（Law of Demeter，LoD） 5.1 定義 （1）應儘量減少其他物件之間的互動，物件只和自己的朋友交談，即對其他依賴的類越少越好（不要和太多的類發生關係）。 （2）儘量不要讓類和類之間建立直接的關係，這樣可減少類與類之間的依賴，降低類之間的耦合。 （3）一

設計模式應試複習篇（九）——11種行為型模式的類圖結構（7~11種）

7、觀察者模式 1）觀察者模式包含如下角色 Subject：目標又稱為主題，它是指被觀察的物件。在目標中定義了一個觀察者集合，一個觀察目標可以接受任意數量的觀察者來觀察，它提供一系列方法來增加和刪除觀察者物件，同時它定義了通知方法notify()。目標類可以是介面，也可以是抽象類或具體類。

設計模式應試複習篇（八）——11種行為型模式的類圖結構（1~6種）

1、職責鏈模式 1）職責鏈模式包含如下角色： Handler：抽象處理者角色，它定義了一個處理請求的介面，一般設計為抽象類，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。因為每一個處理者的下家還是一個處理者，因此在抽象處理者中定義了一個抽象處理者型別的物件（如結構

設計模式簡單小例子（二）結構型模式

簡單小例子 原始碼已經上傳到了GitHub. https://github.com/tanglonghui/DesignPatterns 設計模式簡單小例子（一） 建立型模式： https://blog.csdn.net/qq_40687864/article/details/810

Java設計模式之總體簡介（一）——簡單易懂

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是

設計模式應試複習篇（七）——舉例說明11種行為型模式的適用情景

1、職責鏈模式 很多情況下，在一個軟體系統中可以處理某個請求的物件不止一個，比如我們在學校提交請假的申請表，輔導員、系主任、院長和校長都可以處理申請表，他們可以構成一條處理申請表的鏈式結構，申請表沿著這條鏈進行傳遞，這條鏈就稱為職責鏈。職責鏈可以是一條直線、一個環或者一個樹