国产无圣光,青青草大香蕉超碰,中文字幕无码高清亚洲无码,日本一道本高清在线一区二区,上床视频网站,成人先锋影院,图片区小说区视频区91,毛片视频网站

點擊關注公眾號，Java干貨及時送達

今天我們一起來聊聊關于設計原則相關的知識點。希望能給大家一個參考。如有錯誤或未考慮完全的地方，望不吝賜教。

SOLID五大原則是什么

SRP 單一責任原則

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

舉個例子：

學生管理系統(tǒng)中，我們需要提交一些學生的基本資料，那么學生信息相關的程序都交給了StudentService負責，如果我們要實現(xiàn)一個保存教師基本資料的功能就應該新建一個TeacherService去處理，而不應該寫在StudentService當中。

OCP開放封閉原則

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

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

第一點

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

第二點

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

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

LSP里氏替換原則

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

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

例如：

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

子類不要違背父類對于入?yún)ⅲ鰠ⅲ惓７矫娴募s定。例如：父類對于異常的拋出指定的是 NullPointException ，但是子類卻在實現(xiàn)的時候聲明了會出 illegalArgumentException，那么此時就需要注意到設計已經(jīng)違背了LSP原則。

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

ISP接口隔離原則

理解“接口隔離原則”的重點是理解其中的“接口”二字。

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

如果部分接口只被部分調(diào)用者使用，我們就需要將這部分接口隔離出來，單獨給這部分調(diào)用者使用，而不強迫其他調(diào)用者也依賴這部分不會被用到的接口。

DIP依賴倒置原則

比較經(jīng)典的例子，例如說Spring框架的IOC控制反轉(zhuǎn)，將bean的管理交給了Spring容器去托管。依賴注入則是指不通過明確的new對象的方式來在類中創(chuàng)建類，而是提前將類創(chuàng)建好，然后通過構造函數(shù)，setter函數(shù)等方式將對應的類注入到所需使用的對象當中。

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.

解釋過來就是，高層次的模塊不應該依賴低層次的模塊，不同的模塊之間應該通過接口來互相訪問，而并非直接訪問到對方的具體實現(xiàn)。

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

代碼實戰(zhàn)理解設計原則

單一責任原則案例

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

/**
 * @Author linhao
 * @Date created in 7:22 上午 2021/9/3
 */
public class UserInfo {
    
    private String username;
    private short age;
    private short height;
    private String phone;
    private String home;
    
}

慢慢地隨著業(yè)務的發(fā)展，這個實體類中的home字段開始進行了擴展，UserINfo類變成了以下模式：

/**
 * @Author linhao
 * @Date created in 7:22 上午 2021/9/3
 */
public class UserInfo {
    private String username;
    private short age;
    private short height;
    private String phone;
    private String home;
    /**
     * 省份
     */
    private String province;
    /**
     * 城市
     */
    private String city;
    /**
     * 地區(qū)
     */
    private String region;
    /**
     * 街道
     */
    private String street;
}

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

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

/**
 * @Author linhao
 * @Date created in 7:22 上午 2021/9/3
 */
public class UserInfo {

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

這樣的拆分可以確保UserInfo對象的職責單一，類似的擴展還可以蔓延到后續(xù)的email，tel相關屬性。

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

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

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

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

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

開放封閉原則案例

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

我做的一款社交小程序應用當中，當一個用戶注冊完信息之后，需要通知到系統(tǒng)下游，主要是修改某些后臺數(shù)據(jù)，分配對應的員工去跟進這個用戶。

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

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

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

但是注冊的渠道類型有許多種，例如公眾號，小程序二維碼傳播，小程序的分享鏈接，其他App渠道等等。所以代碼結(jié)構需要做部分調(diào)整：

首先需要修改一開始設計的接口模型：

/**
 * @Author linhao
 * @Date created in 7:56 上午 2021/9/3
 */
public interface IRegisterHandler {
    /**
     * 用戶注冊之后處理函數(shù)
     *
     * @param userId 用戶ID
     * @param sourceId 注冊渠道ID
     */
    void postProcessorAfterRegister(long userId,int sourceId);
}

然后還需要修改實際的實現(xiàn)規(guī)則：

/**
 * @Author linhao
 * @Date created in 7:48 上午 2021/9/3
 */
public class RegisterHandler 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) {
        //通知部分的邏輯
    }
}

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

所以我們可以換一種設計思路去實現(xiàn)。

首先我們需要將注冊的傳入?yún)?shù)定義為一個對象類型，這樣在后續(xù)新增參數(shù)的時候只需調(diào)整對象內(nèi)部的字段即可，不會對原有接口的設計造成影響：

/**
 * @Author linhao
 * @Date created in 8:07 上午 2021/9/3
 */
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模塊：

/**
 * @Author linhao
 * @Date created in 7:56 上午 2021/9/3
 */
public interface IRegisterService {
    /**
     * 用戶注冊之后處理函數(shù)
     *
     * @param registerInputParam 用戶注冊之后的傳入?yún)?shù)
     */
    void postProcessorAfterRegister(RegisterInputParam registerInputParam);
}

注冊處理器內(nèi)部才是真正的核心部分：

/**
 * @Author linhao
 * @Date created in 8:10 上午 2021/9/3
 */
public abstract class AbstractRegisterHandler {
    /**
     * 獲取注冊渠道ID
     *
     * @return
     */
    public abstract int getSource();

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

}

具體的實現(xiàn)交給了各個Handler組件：

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

/**
 * @Author linhao
 * @Date created in 8:16 上午 2021/9/3
 */
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注冊渠道的后置處理器

/**
 * @Author linhao
 * @Date created in 8:16 上午 2021/9/3
 */
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;
        }
    }
}

接下來，對于注冊的后置處理服務接口進行實現(xiàn)：

/**
 * @Author linhao
 * @Date created in 7:48 上午 2021/9/3
 */
public class RegisterServiceImpl implements IRegisterService {

    private static List<AbstractRegisterHandler> 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 Test {

    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參數(shù)。

同時對于后續(xù)業(yè)務的拓展，新增不同的注冊渠道的時候，RegisterServiceImpl只需要添加新編寫的注冊處理器類即可。

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

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

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

里氏替換原則

我認為，里氏替換原則更多是體現(xiàn)在了父子類繼承方面，強調(diào)的是子類在繼承了父類對象的時候不應該破壞這個父類對象的設計初衷。

舉個例子來說：

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

/**
 * @Author linhao
 * @Date created in 11:21 上午 2021/9/4
 */
public interface DrawMoneyService {
    /**
     * 提款函數(shù)
     *
     * @param drawMoneyInputParam
     */
    void drawMoney(DrawMoneyInputParam drawMoneyInputParam);
}

對應的是一個抽象實現(xiàn)父類：

/**
 * @Author linhao
 * @Date created in 11:25 上午 2021/9/4
 */
public abstract class AbstractDrawMoneyServiceImpl implements DrawMoneyService{

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

正常的子類繼承對應父類都應該是對入?yún)⑦M行一個校驗判斷，如果金額數(shù)值小于0，自然就不允許提現(xiàn)了。

/**
 * @Author linhao
 * @Date created in 11:22 上午 2021/9/4
 */
public class AppDrawMoneyServiceImpl extends AbstractDrawMoneyServiceImpl{

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

但是如果某個實現(xiàn)的子類當中違背了這一設計原則，例如下邊這種：

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

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

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

另外說說多態(tài)和里氏替換原則兩個名詞：

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

接口隔離原則

關于接口隔離原則這部分，我們可以通過一個具體的實戰(zhàn)案例來學習。

在和第三方服務進行對接的時候，通常我們需要接入一些密鑰之類的相關信息，例如和支付寶的支付接口對接，和微信支付接口做對接，和銀聯(lián)支付做對接等等。

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

/**
 * 基本的支付配置接口
 * 
 * @Author linhao
 * @Date created in 9:59 上午 2021/9/5
 */
public interface BasePayConfig {
}

然后對每類支付配置都有對應的一個實現(xiàn)方式：

public class BankPayConfig implements BasePayConfig{
    private String secretKey;
    private String appId;
    private String randomNumber;
    //getter和setter省略
}

public class AliPayConfig implements BasePayConfig{
    private String secretKey;
    private String appId;
    private String randomNumber;
}

public class WXPayConfig implements BasePayConfig{
    private String secretKey;
    private String appId;
    private String randomNumber;
}

然后呢，實際場景中我們需要將這些配置信息給展示到一個后臺管理系統(tǒng)的某個模塊當中，所以后續(xù)我便在已有的BasePayConfig接口中定義了一個專門展示支付配置的函數(shù)：

public interface BasePayConfig {

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

展示配置之后，需要在各個子類中去對不同的信息進行組裝，最后返回一個Map的格式給到調(diào)用方。

但是隨著業(yè)務的變動，某天需要對微信支付的配置信息實現(xiàn)可以替換更新的功能，但是額外的支付寶支付，銀聯(lián)支付不允許對外暴露這一權限。那么此時就需要對代碼進行調(diào)整了。

調(diào)整思路一：

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

public interface BasePayConfig {

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

然后各個子類依舊是實現(xiàn)這些接口，并且即使不需要實現(xiàn)更新功能的支付寶配置類，銀聯(lián)配置類都必須強制實現(xiàn)。從這樣的設計角度來思考就會發(fā)現(xiàn)，對于代碼實現(xiàn)方面不是太友好，接口內(nèi)部定義的函數(shù)粒度還可以再分細一些。

調(diào)整思路二：

將讀取配置和更新配置分成兩個接口，需要實現(xiàn)更新配置功能的類才需要去實現(xiàn)該接口。代碼如下所示：

支付配置展示

/**
 * @Author linhao
 * @Date created in 10:19 上午 2021/9/5
 */
public interface BasePayConfigViewer {
    /**
     * 展示配置
     */
    Map<String,Object> showConfig(int code);
}

支付配置更新

public interface BasePayConfigUpdater {

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

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

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

依賴反轉(zhuǎn)原則

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

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

例如我們定義個BeanObject對象：

public interface BeanObject {
    void run();
}

然后再定義相關的實現(xiàn)類，如消息發(fā)送：

public class MessageNotify implements BeanObject{

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

最后是一個Context上下文環(huán)境：

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();
    }
}

從代碼來看，可以發(fā)現(xiàn)對于MessageNotify的調(diào)用均是通過一個BeanContext組件調(diào)用來實現(xiàn)的，而并不是直接通過new MessageNotify的方式去顯示調(diào)用。通過封裝一個基礎骨架容器BeanContext來管控每個BeanObject的run方法執(zhí)行，這樣就將該函數(shù)的調(diào)用權轉(zhuǎn)交給了BeanContext對象管理。

控制反轉(zhuǎn)現(xiàn)在我們再來理解控制反轉(zhuǎn) 這個名詞，“控制”主要是指對程序執(zhí)行流程的控制，例如bean的調(diào)用方式。“反轉(zhuǎn)”則是指程序調(diào)用權限的轉(zhuǎn)變，例如從bean的調(diào)用方轉(zhuǎn)變?yōu)榱嘶A容器。

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

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

最后再來品味下官方對于依賴反轉(zhuǎn)的介紹：

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）不要依賴具體實現(xiàn)細節(jié)（details），具體實現(xiàn)細節(jié)（details）依賴抽象（abstractions）。

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

最后，希望這篇文章能夠?qū)δ阌兴鶈l(fā)。


往
期
推
薦
1、靈魂一問：你的登錄接口真的安全嗎？
2、HashMap 中這些設計，絕了~
3、在 IntelliJ IDEA 中這樣使用 Git，賊方便了！
4、計算機時間到底是怎么來的？程序員必看的時間知識！
5、這些IDEA的優(yōu)化設置趕緊安排起來，效率提升杠杠的！
6、21 款 yyds 的 IDEA插件
7、真香！用 IDEA 神器看源碼，效率真高！
點分享
點收藏
點點贊
點在看