Java專案中常用的的五大設計原則-有解無憂

今天我們一起來聊聊關于設計原則相關的知識點，

SOLID五大原則是什么

SRP 單一責任原則

單一責任原則，從名字上我們就能比較好的去理解它，這項原則主張一個物件只專注于單個方面的邏輯，強調了職責的專一性，

舉個例子：

學生管理系統中，我們需要提交一些學生的基本資料，那么學生資訊相關的程式都交給了StudentService負責，如果我們要實作一個保存教師基本資料的功能就應該新建一個TeacherService去處理，而不應該寫在StudentService當中，

OCP開放封閉原則

這項原則從我個人的角度去理解，它更加強調的是對于擴展的開放性，例如當我們需要調整某些實作邏輯的時候，盡量不要直接改動到原有的實作點，

但是這里面有幾個點容易被人們誤解：

第一點

開放封閉原則雖然強調的是不要隨意改動代原先代碼到邏輯結構，但是并沒有要求一定不能對代碼進行改動！

第二點

同樣是代碼改動，如果我們可以從功能，模塊的角度去看，實際上代碼的改動更多地可以被認作為是一種“擴展”，

關于如何做到開放封閉原則，下文我會專門用一個案例來進行介紹，

LSP里氏替換原則

里氏替換原則強調的是不能破壞一個原有類設計的原始設計體系，強調了子類可以對父類程式進行繼承，但是有幾個點需要注意下：

如果父類定義的規則最好是最基礎，必須遵守的法則，如果子類繼承了父類之后，在某個方法的實作上違背了初衷，那么這樣的設計就是違背了里氏替換法則，

例如：

父類的設計是希望實作商品庫存扣減的功能，但是子類的實作卻是實作了庫存+1的功能，這就很明顯是牛頭不對馬嘴了，

子類不要違背父類對于入參，出參，例外方面的約定，例如：父類對于例外的拋出指定的是 NullPointException ，但是子類卻在實作的時候宣告了會出 illegalArgumentException，那么此時就需要注意到設計已經違背了LSP原則，

同樣，具體的案例我在下文會列舉出來和大家進行代碼分享，

ISP介面隔離原則

理解“介面隔離原則”的重點是理解其中的“介面”二字，

這里有三種不同的理解，如果把“介面”理解為一組介面集合，可以是某個微服務的介面，也可以是某個類別庫的介面等，

如果部分介面只被部分呼叫者使用，我們就需要將這部分介面隔離出來，單獨給這部分呼叫者使用，而不強迫其他呼叫者也依賴這部分不會被用到的介面，

DIP依賴倒置原則

比較經典的例子，例如說Spring框架的IOC控制反轉，將bean的管理交給了Spring容器去托管，依賴注入則是指不通過明確的new物件的方式來在類中創建類，而是提前將類創建好，然后通過建構式，setter函式等方式將對應的類注入到所需使用的物件當中，

DIP的英文解釋大致為：

High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.

解釋過來就是，高層次的模塊不應該依賴低層次的模塊，不同的模塊之間應該通過介面來互相訪問，而并非直接訪問到對方的具體實作，

清楚了這么多理論知識之后，接下來我們通過一些代碼實戰案例來進行更加深入的了解吧，

單一責任原則案例

我們來看這么一個類，簡單的一個用戶資訊類中，包含了一個叫做home的欄位，這個欄位主要用于記錄用戶所居住的位置，

public class UserInfo {

    private String username;
    
    private short age;
    
    private short height;
    
    private String phone;
    
    private String home;
    
}

慢慢地隨著業務的發展，這個物體類中的home欄位開始進行了擴展，UserINfo類變成了以下模式：

public class UserInfo {
    private String username;
    private short age;
    private short height;
    private String phone;
    private String home;
    /**
     * 省份
     */
    private String province;
    /**
     * 城市
     */
    private String city;
    /**
     * 地區
     */
    private String region;
    /**
     * 街道
     */
    private String street;
}

此時對于這個物體類的設計就會有了新的觀點：

這個類中關于居住部分的欄位開始漸漸增加，應該將住址部分抽象出來成一個Address欄位，拆分后變成如下所示：

public class UserInfo {

    private String username;
    private short age;
    private short height;
    private String phone;
    private String home;
    /**地址資訊**/
    private Address address;
    
}

這樣的拆分可以確保UserInfo物件的職責單一，類似的擴展還可以蔓延到后續的email，tel相關屬性，

舉這個例子只是想簡單說明，我們在對一些類進行設計的時候，其實就已經使用到了單一責任原則，另外還有可能在以下場景中也有運用到該原則：

類中的屬性欄位特別多，一個bean中充斥了幾十個屬性，此時也可以嘗試使用單一責任原則，將不同屬性的欄位歸納為一個bean進行收攏，

一個大物件，例如XXXManager或者XXXContext這種名詞定義的物件中，可能引入了一大堆的外部依賴，此時可以按照依賴的類別來進行拆分，

業務代碼塊中，我們定義了一個UserService類，然后這個類里面寫了一坨的用戶密碼，手機號，身份證號解密加密相關的私有函式，這時候可以不妨嘗試將這些私有方法統統抽象成為一個獨立的Util當中，從而減少UserService中的代碼量，

所以最終你會發現，單一責任原則還是一個比較需要依靠主觀意識去拿捏的一項技巧，隨著我們實踐開發經驗的逐漸提升，自然就會明白什么樣的代碼該進行良好的抽象與優化了，

開放封閉原則案例

關于這條原則我個人感覺要想較好地理解它，需要有具體的實戰案例代碼，所以接下來我打算用一個自己曾經在作業中遇到的實際場景和你分享：

我做的一款社交小程式應用當中，當一個用戶注冊完資訊之后，需要通知到系統下游，主要是修改某些后臺資料，分配對應的員工去跟進這個用戶，

所以大體的代碼設計可能如下所示：

public class RegisterHandler {
    public void postProcessorAfterRegister(long userId){
        //通知員工
        notifyWorker(userId);
    }
    
    private void notifyWorker(long userId){
        //通知部分的邏輯
    }
}

public interface IRegisterHandler {
    /**
     * 用戶注冊之后處理函式
     *
     * @param userId 用戶渠道ID
     */
    void postProcessorAfterRegister(long userId);
}

但是注冊的渠道型別有許多種，例如公眾號，小程式二維碼傳播，小程式的分享鏈接，其他App渠道等等，所以代碼結構需要做部分調整：

首先需要修改一開始設計的介面模型：

public interface IRegisterHandler {
    /**
     * 用戶注冊之后處理函式
     *
     * @param userId 用戶ID
     * @param sourceId 注冊渠道ID
     */
    void postProcessorAfterRegister(long userId,int sourceId);
}

然后還需要修改實際的實作規則：

public class RegisterHandlerImpl implements IRegisterHandler {
    @Override
    public void postProcessorAfterRegister(long userId, int sourceId) {
        //通知員工
        if (sourceId == 1) {
            //doSth
        } else if (sourceId == 2) {
            //doSth
        } else if (sourceId == 3) {
            //doSth
        } else {
            //doSth
        }
        notifyWorker(userId, sourceId);
    }

    private void notifyWorker(long userId, int sourceId) {
        //通知部分的邏輯
    }
}

這樣的代碼擴展就會對原先定義好的結構造成破壞，也就不滿足我們所認識的開放封閉原則了，（雖然我在上文中有提及過對于開放封閉原則來說，并不是強制要求不對代碼進行修改，但是現在的這種擴展模式已經對內部結構造成了較大的傷害，）

所以我們可以換一種設計思路去實作，

首先我們需要將注冊的傳入引數定義為一個物件型別，這樣在后續新增引數的時候只需調整物件內部的欄位即可，不會對原有介面的設計造成影響：

public class RegisterInputParam {

    private long userId;

    private int source;

    public long getUserId() {
        return userId;
    }

    public void setUserId(long userId) {
        this.userId = userId;
    }

    public int getSource() {
        return source;
    }

    public void setSource(int source) {
        this.source = source;
    }
}

接著可以將注冊邏輯拆解為注冊處理器和使用注冊處理器的service模塊：

public interface IRegisterService {
    /**
     * 用戶注冊之后處理函式
     *
     * @param registerInputParam 用戶注冊之后的傳入引數
     */
    void postProcessorAfterRegister(RegisterInputParam registerInputParam);
}

注冊處理器內部才是真正的核心部分：

public abstract class AbstractRegisterHandler {
    /**
     * 獲取注冊渠道ID
     *
     * @return
     */
    public abstract int getSource();

    /**
     * 注冊之后的核心通知模塊程式
     *
     * @param registerInputParam
     * @return
     */
    public abstract boolean doPostProcessorAfterRegister(RegisterInputParam registerInputParam);

}

具體的實作交給了各個Handler組件：

公眾號注冊渠道的后置處理器

public class GZHRegisterHandler  extends AbstractRegisterHandler {

    @Override
    public int getSource() {
        return RegisterConstants.RegisterEnum.GZH_CHANNEL.getCode();
    }

    @Override
    public boolean doPostProcessorAfterRegister(RegisterInputParam registerInputParam) {
        System.out.println("公眾號處理邏輯");
        return true;
    }
}

app注冊渠道的后置處理器

public class AppRegisterHandler extends AbstractRegisterHandler {

    @Override
    public int getSource() {
        return RegisterConstants.RegisterEnum.APP_CHANNEL.getCode();
    }

    @Override
    public boolean doPostProcessorAfterRegister(RegisterInputParam registerInputParam) {
        System.out.println("app處理邏輯");
        return true;
    }
}

不同的注冊渠道號通過一個列舉來進行管理：

public class RegisterConstants {

    public enum RegisterEnum{

        GZH_CHANNEL(0,"公眾號渠道"),
        APP_CHANNEL(1,"app渠道");

        RegisterEnum(int code, String desc) {
            this.code = code;
            this.desc = desc;
        }

        int code;
        String desc;

        public int getCode() {
            return code;
        }
    }
}

接下來，對于注冊的后置處理服務介面進行實作：

public class RegisterServiceImpl implements IRegisterService {

    private static List registerHandlerList = new ArrayList<>();

    static {
        registerHandlerList.add(new GZHRegisterHandler());
        registerHandlerList.add(new AppRegisterHandler());
    }

    @Override
    public void postProcessorAfterRegister(RegisterInputParam registerInputParam) {
        for (AbstractRegisterHandler abstractRegisterHandler : registerHandlerList) {
            if(abstractRegisterHandler.getSource()==registerInputParam.getSource()){
                abstractRegisterHandler.doPostProcessorAfterRegister(registerInputParam);
                return;
            }
        }
        throw new RuntimeException("未知注冊渠道號");
    }

}

最后通過簡單的一段測驗程式：

public class TestDesignPrinciple {
    public static void main(String[] args) {
        RegisterInputParam registerInputParam = new RegisterInputParam();
        registerInputParam.setUserId(10012);
        registerInputParam.setSource(0);

        IRegisterService registerService = new RegisterServiceImpl();
        registerService.postProcessorAfterRegister(registerInputParam);

        RegisterInputParam registerInputParam2 = new RegisterInputParam();
        registerInputParam2.setUserId(10013);
        registerInputParam2.setSource(1);
        registerService.postProcessorAfterRegister(registerInputParam2);

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

    }
}

這樣的設計和起初最先前的設計相比有幾處不同的完善點：

新增不同注冊渠道的時候，只需要關心注冊渠道的source引數，

同時對于后續業務的拓展，新增不同的注冊渠道的時候，RegisterServiceImpl只需要添加新撰寫的注冊處理器類即可，

再回過頭來看，這樣的一段代碼設計是否滿足了開放封閉原則呢？

每次新增不同的注冊型別處理邏輯之后，程式中都只需要新增一種Handler處理器，這種處理器對于原先的業務代碼并沒有過多的修改，從整體設計的角度來看，并沒有對原有的代碼結構造成影響，而且靈活度相比之前有所提高，這也正好對應了，對擴展開放，對修改關閉，

如果你對設計模式有一定了解的話，可能還會發現大多數常用的設計模式都在遵守這一項原則，例如模版模式，策略模式，責任鏈模式等等，

里氏替換原則

我認為，里氏替換原則更多是體現在了父子類繼承方面，強調的是子類在繼承了父類物件的時候不應該破壞這個父類物件的設計初衷，

舉個例子來說：

我們定義了一個提款的服務：

public interface DrawMoneyService {
    /**
     * 提款函式
     *
     * @param drawMoneyInputParam
     */
    void drawMoney(DrawMoneyInputParam drawMoneyInputParam);
}

@Data
@ToString
@EqualsAndHashCode
@Builder
public class DrawMoneyInputParam {

    private int money;
}

對應的是一個抽象實作父類：

public abstract class AbstractDrawMoneyServiceImpl implements DrawMoneyService{

    /**
     * 設計初衷，需要對提現金額進行引數校驗
     * 
     * @param drawMoneyInputParam
     */
    @Override
    public abstract void drawMoney(DrawMoneyInputParam drawMoneyInputParam);
}

正常的子類繼承對應父類都應該是對入參進行一個校驗判斷，如果金額數值小于0，自然就不允許提現了，

public class AppDrawMoneyServiceImpl extends AbstractDrawMoneyServiceImpl{

    @Override
    public void drawMoney(DrawMoneyInputParam drawMoneyInputParam) {
        if(drawMoneyInputParam.getMoney()>0){
            //執行提款程式
        }
        System.out.println("app提款業務");
    }
}

但是如果某個實作的子類當中違背了這一設計原則，例如下邊這種：

public class GZHDrawMoneyServiceImpl implements DrawMoneyService {
    @Override
    public void drawMoney(DrawMoneyInputParam drawMoneyInputParam) {
        if(drawMoneyInputParam.getMoney()<0){
            //執行提款程式
        }
        System.out.println("公眾號提款業務");
    }
}

那么這種情況下，子類的實作就違背了最初父類設計的初衷，此時就違背了里氏替換原則的思想，此時就容易給閱讀代碼的人感覺，不同的子類雖然都繼承了同一個父類，但是在轉賬的引數校驗邏輯上完全是東一套，西一套，沒有特定的規矩，邏輯比較亂，

所以較好的做法是在父類中就將需要滿足的基本邏輯定義好，保證子類在進行擴展的時候不會輕易造成修改，

另外說說多型和里氏替換原則兩個名詞：

從案例代碼來看，你會發現似乎多型和里氏替換長得很相似，但是我個人認為這是兩個不同領域的東西，前者是代碼特有的屬性，后者則是一種設計思想，正因為類有了多型的這種特性，人們才會重視在代碼設計程序中需要遵守里氏替換原則，這一項原則在設計的程序中保證了代碼設計的正確性，它更像是一種思路在指導著開發者如何設計出更加好維護和理解的程式，

介面隔離原則

關于介面隔離原則這部分，我們可以通過一個具體的實戰案例來學習，

在和第三方服務進行對接的時候，通常我們需要接入一些密鑰之類的相關資訊，例如和支付寶的支付介面對接，和微信支付介面做對接，和銀聯支付做對接等等，

那么我們可以將這些不同場景下關于支付相關的資訊的儲存放在一個Config相關的物件中，如下所示：

public interface BasePayConfig {
}

然后對每類支付配置都有對應的一個實作方式：

@Data
@ToString
@EqualsAndHashCode
@Builder
public class BankPayConfig implements BasePayConfig {
    
    private String secretKey;
    
    private String appId;
    
    private String randomNumber;
}

@Data
@ToString
@EqualsAndHashCode
@Builder
public class AliPayConfig implements BasePayConfig {

    private String secretKey;

    private String appId;

    private String randomNumber;
}

@Data
@ToString
@EqualsAndHashCode
@Builder
public class WXPayConfig implements BasePayConfig {

    private String secretKey;

    private String appId;

    private String randomNumber;
}

然后呢，實際場景中我們需要將這些配置資訊給展示到一個后臺管理系統的某個模塊當中，所以后續我便在已有的BasePayConfig介面中定義了一個專門展示支付配置的函式：

public interface BasePayConfig {

    /**
     * 展示配置
     */
    Map<String,Object> showConfig();
}

展示配置之后，需要在各個子類中去對不同的資訊進行組裝，最后回傳一個Map的格式給到呼叫方，

但是隨著業務的變動，某天需要對微信支付的配置資訊實作可以替換更新的功能，但是額外的支付寶支付，銀聯支付不允許對外暴露這一權限，那么此時就需要對代碼進行調整了，

調整思路一：

直接在BasePayConfig介面中進行擴展,代碼案例如下：

public interface BasePayConfig {

    /**
     * 展示配置
     */
    Map<String,Object> showConfig(int code);
    
    /**
     * 更新配置資訊
     * 
     * @return
     */
    Map<String,Object> updateConfig();
}

然后各個子類依舊是實作這些介面，并且即使不需要實作更新功能的支付寶配置類，銀聯配置類都必須強制實作，從這樣的設計角度來思考就會發現，對于代碼實作方面不是太友好，介面內部定義的函式粒度還可以再分細一些，

調整思路二：

將讀取配置和更新配置分成兩個介面，需要實作更新配置功能的類才需要去實作該介面，代碼如下所示：

支付配置展示

public interface BasePayConfigViewer {
    /**
     * 展示配置
     */
    Map<String,Object> showConfig(int code);
}

支付配置更新

public interface BasePayConfigUpdater {

    /**
     * 更新配置資訊
     *
     * @return
     */
    Map<String,Object> updateConfig();
}

這樣的設計能夠保證，不同的介面專門負責不同的領域，只有當實作類確實需要使用該功能的時候才去實作該介面，寫到這里的時候，你可以不妨再回過頭去理解下我在文章上半部分中提及的介面隔離原則，相信你會有新的體會，

或許你也會有所疑惑，介面隔離原則好像和單一責任原則有些類似呀，都是各自專一地負責自己所管理的部分，但是我個人認為，介面隔離原則關注的是介面，而單一責任原則關注的目標可以是物件，介面，類，所涉及的領域更加廣闊一些，

依賴反轉原則

在介紹依賴反轉原則之前，我們先來理解一個相似的名詞，控制反轉，

單純的從Java程式來進行理解：

例如我們定義個BeanObject物件：

public interface BeanObject {
    void run();
}

然后再定義相關的實作類，如訊息發送：

public class MessageNotify implements BeanObject{

    @Override
    public void run() {
        System.out.println("訊息發送");
    }
}

最后是一個Context背景關系環境：

public class BeanContext {

    private static List<BeanObject> beanObjectList = new ArrayList<>();

    static {
        beanObjectList.add(new MessageNotify());
    }

    public static void main(String[] args) {
        beanObjectList.get(0).run();
    }
}

從代碼來看，可以發現對于MessageNotify的呼叫均是通過一個BeanContext組件呼叫來實作的，而并不是直接通過new MessageNotify的方式去顯示呼叫，通過封裝一個基礎骨架容器BeanContext來管控每個BeanObject的run方法執行，這樣就將該函式的呼叫權轉交給了BeanContext物件管理，

控制反轉現在我們再來理解控制反轉這個名詞，“控制”主要是指對程式執行流程的控制，例如bean的呼叫方式，“反轉”則是指程式呼叫權限的轉變，例如從bean的呼叫方轉變為了基礎容器，

依賴注入再來聊下依賴注入這個名詞，

依賴注入強調的是將依賴屬性不要通過顯式的new方式來創建注入，而是將其交給了基礎框架去管理，這方面的代表框架除了我們熟悉的Spring之外，其實還有很多，例如Pico Contanier等，

最后再來品味下官方對于依賴反轉的介紹：

High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.

高層模塊（high-level modules）不要依賴低層模塊（low-level），高層模塊和低層模塊應該通過抽象（abstractions）來互相依賴，除此之外，抽象（abstractions）不要依賴具體實作細節（details），具體實作細節（details）依賴抽象（abstractions），

依賴反轉原則也叫作依賴倒置原則，這條原則跟控制反轉有點類似，主要用來指導框架層面的設計，高層模塊不依賴低層模塊，它們共同依賴同一個抽象，抽象不要依賴具體實作細節，具體實作細節依賴抽象，

最后，希望這篇文章能夠對你有所啟發，

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

標籤：Java

上一篇：JDK成長記15：從0分析你不知道的synchronized底層原理（上）

下一篇：你還在用 Postman？IDEA REST Client 好用到爆，Postman 可以扔了...