概述

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

開閉原則：是所有面向對象設計的核心，對擴展開放，對修改關閉
依賴倒置原則：針對接口編程，依賴於抽象而不依賴於具體
單一職責原則：一個接口只負責一件事情，只能有一個原因導致類變化
接口隔離原則：使用多個專門的接口，而不是使用一個總接口
迪米特法則（最少知道原則）：只和朋友交流（成員變量、方法輸入輸出參數），不和陌生人說話，控制好訪問修飾符
里氏替換原則：子類可以擴展父類的功能，但不能改變父類原有的功能
合成複用原則：儘量使用對象組合(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 的子類型。

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

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

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

示例

在前面講開閉原則的時候埋下了一個伏筆，我們記得在獲取折後時重寫覆蓋了父類的 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;
    }
}

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

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

現在來描述一個經典的業務場景，用正方形、矩形和四邊形的關係說明裏氏替換原則，我們都知道正方形是一個特殊的長方形，那麼就可以創建一個長方形父類 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 長方形。當然，我們在後面的設計模式系列文章中中還會繼續深入講解。

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

概述

迪米特法則

定義

示例

里氏替換原則

定義

示例

設計模式 - 策略模式

設計模式 - 策略模式

設計模式 - 委派模式

設計模式 - 動態代理原理及模仿JDK Proxy 寫一個屬於自己的動態代理

設計模式 - 工廠模式

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結