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）。

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

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