概述

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

單一職責原則

定義

單一職責(Simple Responsibility Pinciple，SRP)是指不要存在多于一個導致類變更的原因，

假設我們有一個 Class 負責兩個職責，一旦發生需求變更，修改其中一個職責的邏輯代碼，有可能會導致另一個職責的功能發生故障，這樣一來，這個 Class 存在兩個導致類變更的原因，如何解決這個問題呢?我們就要給兩個職責分別用兩個 Class 來實作，進行解耦，后期需求變更維護互不影響，這樣的設計，可以降低類的復雜度，提高類的可讀性，提高系統的可維護性，降低變更引起的風險，總體來說就是一個 Class/Interface/Method 只負責一項職責，

示例

接下來我們參考《設計模式之禪》一書中所提到關于用戶資訊管理的示例來舉例：

新建用戶資訊IUserInfo類：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:07
 */
public interface IUserInfo {
    void setUserID(String userID);
    String getUserID();
    void setPassword(String password);
    String getPassword();
    void setUserName(String userName);
    String getUserName();
    boolean changePassword(String oldPassword);
    boolean deleteUser();
    void mapUser();
    boolean addOrg(int orgID);
    boolean addRole(int roleID);
}

用戶資訊維護類圖：

用戶資訊維護類圖

如果像這樣子來設計，即使是一個初級程式員也可以看出這個解耦設計得有問題，用戶的屬性和用戶的行為沒有分離開，應該把用戶的資訊抽離成為一個BO，把行為抽離成為一個Biz（業務邏輯），然后我們修改這個介面，
創建 IUserBo 類：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:18
 */
public interface IUserBO {
    void setUserID(String userID);
    String getUserID();
    void setPassword(String password);
    String getPassword();
    void setUserName(String userName);
    String getUserName();
}

創建 IUserBiz 類：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:18
 */
public interface IUserBiz {
    boolean changePassword(String oldPassword);
    boolean deleteUser();
    void mapUser();
    boolean addOrg(int orgID);
    boolean addRole(int roleID);
}

職責劃分后的類圖：

我們將IUserInfo拆分為了IUserBo和IUserBiz，我們就實作了兩個類的單一職責,也就是讓引起他們變化原因只有一種,并且讓相關性強的內容聚合在一個類內部，

但是，我們在實際開發中會專案依賴，組合，聚合這些關系，還有還有專案的規模，周期，技術人員的水平，對進度的把控，很多類都不符合單一職責，但是，我們在撰寫代碼的程序，盡可能地讓介面和方法保持 單一職責，對我們專案后期的維護是有很大幫助的，

介面隔離原則

定義

介面隔離原則(Interface Segregation Principle, ISP)是指用多個專門的介面，而不使用單一的總介面，客戶端不應該依賴它不需要的介面，這個原則指導我們在設計介面時應當注意一下幾點:

一個類對一類的依賴應該建立在最小的介面之上，
建立單一介面，不要建立龐大臃腫的介面，
盡量細化介面，介面中的方法盡量少(不是越少越好，一定要適度)，

介面隔離原則符合我們常說的高內聚低耦合的設計思想，從而使得類具有很好的可讀性、可擴展性和可維護性，我們在設計介面的時候，要多花時間去思考，要考慮業務模型，包括以后有可能發生變更的地方還要做一些預判，所以，對于抽象，對業務模型的理解是非常重要的，

示例

下面我們來看一段代碼，寫一個動物行為的抽象:

IAnimal 介面：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:56
 */
public interface IAnimal {
    void eat();
    void fly();
    void swim();
}

Bird 類實作:

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:57
 */
public class Bird implements IAnimal {
    public void eat() {
    }

    public void fly() {
    }

    public void swim() {
    }
}

Dog 類實作:

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:57
 */
public class Dog implements IAnimal {
    public void eat() {
    }

    public void fly() {
    }

    public void swim() {
    }
}

可以看出，Bird 的 swim()方法可能只能空著，Dog 的 fly()方法顯然不可能的，這時候，我們針對不同動物行為來設計不同的介面，分別設計 IEatAnimal，IFlyAnimal 和 ISwimAnimal 介面，來看代碼:

IEatAnimal 介面：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:59
 */
public interface IEatAnimal {
    void eat();
}

IFlyAnimal 介面：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午5:01
 */
public interface IFlyAnimal {
    void fly();
}

ISwimAnimal 介面：

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午5:02
 */
public interface ISwimAnimal {
    void swim();
}

Dog 只實作 IEatAnimal 和 ISwimAnimal 介面:

/**
 * @author eamon.zhang
 * @date 2019-09-25 下午4:57
 */
public class Dog implements IEatAnimal,ISwimAnimal {

    public void eat() {

    }

    public void swim() {

    }
}

來看下兩種類圖的對比，還是非常清晰明了的:

宣告

內容為原創，轉發請注明出處！
部分內容參考網路，侵刪！

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

標籤：設計模式

上一篇：設計模式 - 七大設計原則（一）

下一篇：設計模式模式（四）：建造者模式（生成器模式）

設計模式 - 七大設計原則（二）

概述

單一職責原則

定義

示例

介面隔離原則

定義

示例

宣告