前言

在軟件架構(gòu)設(shè)計(jì)領(lǐng)域，有一個(gè)大名鼎鼎的設(shè)計(jì)原則——SOLID原則，它是由由Robert C. Martin（也稱為 Uncle Bob）提出的，指導(dǎo)我們寫出可維護(hù)、可以測(cè)試、高擴(kuò)展、高內(nèi)聚、低耦合的代碼。是不是很牛，但是你們都理解這個(gè)設(shè)計(jì)原則嗎，如果理解不深入的話，更這我通過JAVA示例深入淺出的明白這個(gè)重要的原則吧。SOLID實(shí)際上是由5條原則組成, 我們逐一介紹。

S：?jiǎn)我宦氊?zé)原則（SRP）
O : 開閉原則 (OSP)
L : 里氏替換原則 (LSP)
I：接口隔離原則（ISP）
D：依賴倒置原則（DIP）

單一職責(zé)原則（SRP）

這個(gè)原則指出“一個(gè)類應(yīng)該只有一個(gè)改變的理由”，這意味著每個(gè)類都應(yīng)該有單一的責(zé)任或單一的目的。
舉個(gè)例子來理解其中的核心思想，假設(shè)有一個(gè)BankService的類需要執(zhí)行以下操作：

1.存錢
2.取錢
3.打印通票簿
4.獲取貸款信息
5.發(fā)送一次性密碼

package com.alvin.solid.srp;


public class BankService {

    // 存錢
    public long deposit(long amount, String accountNo) {
        //deposit amount
        return 0;
    }

    // 取錢
    public long withDraw(long amount, String accountNo) {
        //withdraw amount
        return 0;
    }

    // 打印通票簿
    public void printPassbook() {
        //update transaction info in passbook
    }

    // 獲取貸款信息
    public void getLoanInterestInfo(String loanType) {
        if (loanType.equals("homeLoan")) {
            //do some job
        }
        if (loanType.equals("personalLoan")) {
            //do some job
        }
        if (loanType.equals("car")) {
            //do some job
        }
    }

    // 發(fā)送一次性密碼
    public void sendOTP(String medium) {
        if (medium.equals("email")) {
            //write email related logic
            //use JavaMailSenderAPI
        }
    }

}

現(xiàn)在我們來看看這么寫會(huì)帶來什么問題？

比如對(duì)于獲取貸款信息 getLoanInterestInfo() 方法，現(xiàn)在銀行服務(wù)只提供個(gè)人貸款、房屋貸款和汽車貸款的信息，假設(shè)將來銀行的人想要提供一些其他貸款功能，如黃金貸款和學(xué)習(xí)貸款，那么你需要修改這個(gè)類實(shí)現(xiàn)對(duì)嗎？

同樣，考慮 sendOTP() 方法，假設(shè) BankService 支持將 OTP 媒體作為電子郵件發(fā)送，但將來他們可能希望引入將 OTP 媒體通過手機(jī)短信發(fā)送，這時(shí)候需要再次修改BankService來實(shí)現(xiàn)。

發(fā)現(xiàn)沒有，它不遵循單一職責(zé)原則，因?yàn)檫@個(gè)類有許多責(zé)任或任務(wù)要執(zhí)行，不僅會(huì)讓BankService這個(gè)類很龐大，可維護(hù)性差。

為了實(shí)現(xiàn)單一職責(zé)原則的目標(biāo)，我們應(yīng)該實(shí)現(xiàn)一個(gè)單獨(dú)的類，它只執(zhí)行單一的功能。

• 打印相關(guān)的工作PrinterService

public class PrinterService {
    public void printPassbook() {
        //update transaction info in passbook
    }
}

• 貸款相關(guān)的工作LoanService

public class LoanService {
    public void getLoanInterestInfo(String loanType) {
        if (loanType.equals("homeLoan")) {
            //do some job
        }
        if (loanType.equals("personalLoan")) {
            //do some job
        }
        if (loanType.equals("car")) {
            //do some job
        }
    }
}

• 通知相關(guān)的工作NotificationService

public class NotificationService{
    public void sendOTP(String medium) {
        if (medium.equals("email")) {
            //write email related logic
            //use JavaMailSenderAPI
        }
    }
}

現(xiàn)在，如果你觀察到每個(gè)類都有單一的責(zé)任來執(zhí)行他們的任務(wù)。這正是 單一職責(zé) SRP 的核心思想。

開閉原則（OSP）

該原則指出“軟件實(shí)體（類、模塊、函數(shù)等）應(yīng)該對(duì)擴(kuò)展開放，但對(duì)修改關(guān)閉”，這意味著您應(yīng)該能夠擴(kuò)展類行為，而無需修改它。

讓我們通過一個(gè)例子來理解這個(gè)原則。讓我們考慮一下我們剛剛創(chuàng)建的同一個(gè)通知服務(wù)。

public class NotificationService {
    public void sendOTP(String medium) {
        if (medium.equals("email")) {
            //write email related logic
            //use JavaMailSenderAPI
        }
    }
}

如前所述，如果您想通過手機(jī)號(hào)碼發(fā)送 OTP，那么您需要修改 NotificationService，對(duì)嗎？

但是根據(jù)OSP原則，對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉, 因此不建議為增加一個(gè)通知方式就修改NotificationService類，而是要擴(kuò)展，怎么擴(kuò)展呢？

• 定義一個(gè)通知服務(wù)接口

public interface NotificationService {
    public void sendOTP();
}

• E-mail方式通知類EmailNotification

public class EmailNotification implements NotificationService{
    public void sendOTP(){
        // write Logic using JavaEmail api
    }
}

• 手機(jī)方式通知類MobileNotification

public class MobileNotification implements NotificationService{
    public void sendOTP(){
        // write Logic using Twilio SMS API
    }
}

• 同樣可以添加微信通知服務(wù)的實(shí)現(xiàn)WechatNotification

public class WechatNotification implements NotificationService{
    public void sendOTP(String medium){
        // write Logic using wechat API
    }
}

這樣的方式就是遵循開閉原則的，你不用修改核心的業(yè)務(wù)邏輯，這樣可能帶來意向不到的后果，而是擴(kuò)展實(shí)現(xiàn)方式，由調(diào)用方根據(jù)他們的實(shí)際情況調(diào)用。

里氏替換原則（LSP）

該原則指出“派生類或子類必須可替代其基類或父類”。換句話說，如果類 A 是類 B 的子類型，那么我們應(yīng)該能夠在不中斷程序行為的情況下用 A 替換 B。

這個(gè)原理有點(diǎn)棘手和有趣，它是基于繼承概念設(shè)計(jì)的，所以讓我們通過一個(gè)例子更好地理解它。

讓我們考慮一下我有一個(gè)名為 SocialMedia 的抽象類，它支持所有社交媒體活動(dòng)供用戶娛樂，如下所示：

package com.alvin.solid.lsp;

public abstract class SocialMedia {
    
    public abstract  void chatWithFriend();
    
    public abstract void publishPost(Object post);
    
    public abstract  void sendPhotosAndVideos();
    
    public abstract  void groupVideoCall(String... users);
}

社交媒體可以有多個(gè)實(shí)現(xiàn)或可以有多個(gè)子類，如 Facebook、Wechat、Weibo 和 Twitter 等。

現(xiàn)在讓我們假設(shè) Facebook 想要使用這個(gè)特性或功能。

package com.alvin.solid.lsp;

public class Wechat extends SocialMedia {

    public void chatWithFriend() {
        //logic  
    }

    public void publishPost(Object post) {
        //logic  
    }

    public void sendPhotosAndVideos() {
        //logic  
    }

    public void groupVideoCall(String... users) {
        //logic  
    }
}

我們都知道Facebook都提供了所有上述的功能，所以這里我們可以認(rèn)為Facebook是SocialMedia類的完全替代品，兩者都可以無中斷地替代。
現(xiàn)在讓我們討論 Weibo 類

package com.alvin.solid.lsp;

public class Weibo extends SocialMedia {
    public void chatWithFriend() {
        //logic
    }

    public void publishPost(Object post) {
      //logic
    }

    public void sendPhotosAndVideos() {
      //logic
    }

    public void groupVideoCall(String... users) {
        //不適用
    }
}

我們都知道Weibo微博這個(gè)產(chǎn)品是沒有群視頻功能的，所以對(duì)于 groupVideoCall方法來說 Weibo 子類不能替代父類 SocialMedia。所以我們認(rèn)為它是不符合里式替換原則。

那有什么解決方案嗎？

那就把功能拆開唄。

public interface SocialMedia {   
   public void chatWithFriend(); 
   public void sendPhotosAndVideos() 
}

public interface SocialPostAndMediaManager { 
    public void publishPost(Object post); 
}

public interface VideoCallManager{ 
   public void groupVideoCall(String... users); 
}

現(xiàn)在，如果您觀察到我們將特定功能隔離到單獨(dú)的類以遵循LSP。

現(xiàn)在由實(shí)現(xiàn)類決定支持功能，根據(jù)他們所需的功能，他們可以使用各自的接口，例如 Weibo 不支持視頻通話功能，因此 Weibo 實(shí)現(xiàn)可以設(shè)計(jì)成這樣：

public class Instagram implements SocialMedia,SocialPostAndMediaManager{
    public void chatWithFriend(){
    //logic
    }
    public void sendPhotosAndVideos(){
    //logic
    }
    public void publishPost(Object post){
    //logic
    }
}

這樣子就是符合里式替換原則LSP。

接口隔離原則（ISP）

這個(gè)原則是第一個(gè)適用于接口而不是 SOLID 中類的原則，它類似于單一職責(zé)原則。它聲明“不要強(qiáng)迫任何客戶端實(shí)現(xiàn)與他們無關(guān)的接口”。

例如，假設(shè)您有一個(gè)名為 UPIPayment 的接口，如下所示

public interface UPIPayments {
    
    public void payMoney();
    
    public void getScratchCard();
    
    public void getCashBackAsCreditBalance();
}

現(xiàn)在讓我們談?wù)?UPIPayments 的一些實(shí)現(xiàn)，比如 Google Pay 和 AliPay。

Google Pay 支持這些功能所以他可以直接實(shí)現(xiàn)這個(gè) UPIPayments 但 AliPay 不支持 getCashBackAsCreditBalance() 功能所以這里我們不應(yīng)該強(qiáng)制客戶端 AliPay 通過實(shí)現(xiàn) UPIPayments 來覆蓋這個(gè)方法。

我們需要根據(jù)客戶需要分離接口，所以為了支持這個(gè)ISP，我們可以如下設(shè)計(jì)：

創(chuàng)建一個(gè)單獨(dú)的接口來處理現(xiàn)金返還。

public interface CashbackManager{ 
    public void getCashBackAsCreditBalance(); 
}

現(xiàn)在我們可以從 UPIPayments 接口中刪除getCashBackAsCreditBalance ，AliPay也不需要實(shí)現(xiàn)getCashBackAsCreditBalance()這個(gè)它沒有的方法了。

依賴倒置原則（DIP）

該原則指出我們需要使用抽象（抽象類和接口）而不是具體實(shí)現(xiàn)，高級(jí)模塊不應(yīng)該直接依賴于低級(jí)模塊，但兩者都應(yīng)該依賴于抽象。

我們直接上例子來理解。

假如你去當(dāng)?shù)匾患疑痰曩I東西，并決定使用刷卡付款。因此，當(dāng)您將卡交給店員進(jìn)行付款時(shí)，店員不會(huì)檢查你提供的是哪種卡，借記卡還是信用卡，他們只會(huì)進(jìn)行刷卡，這就是店員和你之間傳遞“卡”這個(gè)抽象。

現(xiàn)在讓我們用代碼替換這個(gè)例子，以便更好地理解它。

• 借記卡

public class DebitCard { 
    public void doTransaction(int amount){ 
        System.out.println("tx done with DebitCard"); 
    } 
}

• 信用卡

public class CreditCard{ 
    public void doTransaction(int amount){ 
        System.out.println("tx done with CreditCard"); 
    } 
}

現(xiàn)在用這兩張卡你去購物中心購買了一些訂單并決定使用信用卡支付

public class ShoppingMall {
    private DebitCard debitCard;
    public ShoppingMall(DebitCard debitCard) {
        this.debitCard = debitCard;
    }
    public void doPayment(Object order, int amount){              debitCard.doTransaction(amount); 
    }
    public static void main(String[] args) {
        DebitCard debitCard=new DebitCard();
        ShoppingMall shoppingMall=new ShoppingMall(debitCard);
        shoppingMall.doPayment("some order",5000);
    }
}

上面的做法是一個(gè)錯(cuò)誤的方式，因?yàn)?ShoppingMall 類與 DebitCard 緊密耦合。

現(xiàn)在你的借記卡余額不足，想使用信用卡，那么這是不可能的，因?yàn)?ShoppingMall 與借記卡緊密結(jié)合。

當(dāng)然你也可以這樣做，從構(gòu)造函數(shù)中刪除借記卡并注入信用卡。但這不是一個(gè)好的方式，它不符合依賴倒置原則。

那該如何正確設(shè)計(jì)呢？

• 定義依賴的抽象接口BankCard

public interface BankCard { 
  public void doTransaction(int amount); 
}

• 現(xiàn)在 DebitCard 和 CreditCard 都實(shí)現(xiàn)BankCard

public class CreditCard implements BankCard{
    public void doTransaction(int amount){            
        System.out.println("tx done with CreditCard");
    }
}

public class DebitCard implements BankCard { 
    public void doTransaction(int amount){ 
        System.out.println("tx done with DebitCard"); 
    } 
}

• 現(xiàn)在重新設(shè)計(jì)購物中心這個(gè)高級(jí)類，他也是去依賴這個(gè)抽象，而不是直接低級(jí)模塊的實(shí)現(xiàn)類

public class ShoppingMall {
    private BankCard bankCard;
    public ShoppingMall(BankCard bankCard) {
        this.bankCard = bankCard;
    }
    public void doPayment(Object order, int amount){
        bankCard.doTransaction(amount);
    }
    public static void main(String[] args) {
        BankCard bankCard=new CreditCard();
        ShoppingMall shoppingMall1=new ShoppingMall(bankCard);
        shoppingMall1.doPayment("do some order", 10000);
    }
}

現(xiàn)在，如果您觀察購物中心與 BankCard 松散耦合，任何類型的卡處理支付都不會(huì)產(chǎn)生任何影響，這就是符合依賴倒置原則的。

總結(jié)

我們?cè)賮砘仡櫩偨Y(jié)下SOLID原則，

單一職責(zé)原則：每個(gè)類應(yīng)該負(fù)責(zé)系統(tǒng)的單個(gè)部分或功能。

開閉原則：軟件組件應(yīng)該對(duì)擴(kuò)展開放，而不是對(duì)修改開放。

里式替換原則：超類的對(duì)象應(yīng)該可以用其子類的對(duì)象替換而不破壞系統(tǒng)。

接口隔離原則不應(yīng)強(qiáng)迫客戶端依賴于它不使用的方法。

依賴倒置原則：高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴抽象。

這些原則看起來都很簡(jiǎn)單，但用起來用的好就比較難了，希望大家在平時(shí)的開發(fā)的過程中多多思考、多多實(shí)踐。