一. 如何理解“對(duì)擴(kuò)展開(kāi)放、修改關(guān)閉”？

具體的說(shuō)，添加一個(gè)新的功能應(yīng)該是，在已有代碼基礎(chǔ)上擴(kuò)展代碼（新增模塊、類、方法等），而非修改已有代碼（修改模塊、類、方法等）。

舉例說(shuō)明：

//業(yè)務(wù)邏輯主要集中在 check() 函數(shù)中。當(dāng)接口的 TPS 超過(guò)某個(gè)預(yù)先設(shè)置的最大值時(shí)，以及當(dāng)接口請(qǐng)求出錯(cuò)數(shù)大于某個(gè)最大允許值時(shí)，就會(huì)觸發(fā)告警，通知接口的相關(guān)負(fù)責(zé)人或者團(tuán)隊(duì)。

public class Alert {
  private AlertRule rule;
  private Notification notification;

  public Alert(AlertRule rule, Notification notification) {
    this.rule = rule;
    this.notification = notification;
  }

  public void check(String api, long requestCount, long errorCount, long durationOfSeconds) {
    long tps = requestCount / durationOfSeconds;
    if (tps > rule.getMatchedRule(api).getMaxTps()) {
      notification.notify(NotificationEmergencyLevel.URGENCY, "...");
    }
    if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {
      notification.notify(NotificationEmergencyLevel.SEVERE, "...");
    }
  }
}

現(xiàn)在，如果我們需要添加一個(gè)功能，當(dāng)每秒鐘接口超時(shí)請(qǐng)求個(gè)數(shù)，超過(guò)某個(gè)預(yù)先設(shè)置的最大閾值時(shí)，我們也要觸發(fā)告警發(fā)送通知。

?

通過(guò)修改已有代碼來(lái)實(shí)現(xiàn)

//- 第一處是修改 check() 函數(shù)的入?yún)ⅲ砑右粋€(gè)新的統(tǒng)計(jì)數(shù)據(jù) timeoutCount，表示超時(shí)接口請(qǐng)求數(shù)；
//- 第二處是在 check() 函數(shù)中添加新的告警邏輯。
public class Alert {
...
  
  // 改動(dòng)一：添加參數(shù)timeoutCount
  public void check(String api, long requestCount, long errorCount, long timeoutCount, long durationOfSeconds) {
    long tps = requestCount / durationOfSeconds;
    if (tps > rule.getMatchedRule(api).getMaxTps()) {
      notification.notify(NotificationEmergencyLevel.URGENCY, "...");
    }
    if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {
      notification.notify(NotificationEmergencyLevel.SEVERE, "...");
    }
    // 改動(dòng)二：添加接口超時(shí)處理邏輯
    long timeoutTps = timeoutCount / durationOfSeconds;
    if (timeoutTps > rule.getMatchedRule(api).getMaxTimeoutTps()) {
      notification.notify(NotificationEmergencyLevel.URGENCY, "...");
    }
  }
}

這樣的代碼修改實(shí)際上存在挺多問(wèn)題的。

• 一方面，我們對(duì)接口進(jìn)行了修改，這就意味著調(diào)用這個(gè)接口的代碼都要做相應(yīng)的修改。
• 另一方面，修改了 check() 函數(shù)，相應(yīng)的單元測(cè)試都需要修改（關(guān)于單元測(cè)試的內(nèi)容我們?cè)谥貥?gòu)那部分會(huì)詳細(xì)介紹）。

?
通過(guò)“擴(kuò)展”的方式來(lái)實(shí)現(xiàn)同樣的功能

先重構(gòu)一下之前的 Alert 代碼，讓它的擴(kuò)展性更好一些。

• 重構(gòu)一：將 check() 的入?yún)⒎庋b到 ApiStatInfo 類；
• 重構(gòu)二：引入 handler 的概念，將 if 判斷邏輯分散在各個(gè) handler 中。

public class Alert {
  private List<AlertHandler> alertHandlers = new ArrayList<>();
  
  public void addAlertHandler(AlertHandler alertHandler) {
    this.alertHandlers.add(alertHandler);
  }
//封裝入?yún)?/span>
  public void check(ApiStatInfo apiStatInfo) {
    for (AlertHandler handler : alertHandlers) {
      handler.check(apiStatInfo);
    }
  }
}

public class ApiStatInfo {//省略constructor/getter/setter方法
  private String api;
  private long requestCount;
  private long errorCount;
  private long durationOfSeconds;
}


//2. 添加handler抽象類：定義公共屬性和方法
public abstract class AlertHandler {
  protected AlertRule rule;
  protected Notification notification;
  public AlertHandler(AlertRule rule, Notification notification) {
    this.rule = rule;
    this.notification = notification;
  }
  public abstract void check(ApiStatInfo apiStatInfo);
}

public class TpsAlertHandler extends AlertHandler {
  public TpsAlertHandler(AlertRule rule, Notification notification) {
    super(rule, notification);
  }

  @Override
  public void check(ApiStatInfo apiStatInfo) {
    long tps = apiStatInfo.getRequestCount()/ apiStatInfo.getDurationOfSeconds();
    if (tps > rule.getMatchedRule(apiStatInfo.getApi()).getMaxTps()) {
      notification.notify(NotificationEmergencyLevel.URGENCY, "...");
    }
  }
}

public class ErrorAlertHandler extends AlertHandler {
  public ErrorAlertHandler(AlertRule rule, Notification notification){
    super(rule, notification);
  }

  @Override
  public void check(ApiStatInfo apiStatInfo) {
    if (apiStatInfo.getErrorCount() > rule.getMatchedRule(apiStatInfo.getApi()).getMaxErrorCount()) {
      notification.notify(NotificationEmergencyLevel.SEVERE, "...");
    }
  }
}

在重構(gòu)之后的代碼中實(shí)現(xiàn)新的需求，有如下改動(dòng)

• 在 ApiStatInfo 類中添加新的屬性 timeoutCount。
• 添加新的 TimeoutAlertHander 類。
• 在 ApplicationContext 類的 initializeBeans() 方法中，往 alert 對(duì)象中注冊(cè)新的 timeoutAlertHandler。
• 在使用 Alert 類的時(shí)候，需要給 check() 函數(shù)的入?yún)?apiStatInfo 對(duì)象設(shè)置 timeoutCount 的值。

public class Alert { // 代碼未改動(dòng)... }
public class ApiStatInfo {//省略constructor/getter/setter方法
  private String api;
  private long requestCount;
  private long errorCount;
  private long durationOfSeconds;
  private long timeoutCount; // 改動(dòng)一：添加新字段
}
public abstract class AlertHandler { //代碼未改動(dòng)... }
public class TpsAlertHandler extends AlertHandler {//代碼未改動(dòng)...}
public class ErrorAlertHandler extends AlertHandler {//代碼未改動(dòng)...}

// 改動(dòng)二：添加新的handler
public class TimeoutAlertHandler extends AlertHandler {//省略代碼...}

public class ApplicationContext {
  private AlertRule alertRule;
  private Notification notification;
  private Alert alert;
  
  public void initializeBeans() {
    alertRule = new AlertRule(/*.省略參數(shù).*/); //省略一些初始化代碼
    notification = new Notification(/*.省略參數(shù).*/); //省略一些初始化代碼
    alert = new Alert();
    alert.addAlertHandler(new TpsAlertHandler(alertRule, notification));
    alert.addAlertHandler(new ErrorAlertHandler(alertRule, notification));
    // 改動(dòng)三：注冊(cè)handler
    alert.addAlertHandler(new TimeoutAlertHandler(alertRule, notification));
  }
  //...省略其他未改動(dòng)代碼...
}

public class Demo {
  public static void main(String[] args) {
    ApiStatInfo apiStatInfo = new ApiStatInfo();
    // ...省略apiStatInfo的set字段代碼
    apiStatInfo.setTimeoutCount(289); // 改動(dòng)四：設(shè)置tiemoutCount值
    ApplicationContext.getInstance().getAlert().check(apiStatInfo);
}

重構(gòu)之后的代碼更加靈活和易擴(kuò)展。

如果我們要想添加新的告警邏輯，只需要基于擴(kuò)展的方式創(chuàng)建新的 handler 類即可，不需要改動(dòng)原來(lái)的 check() 函數(shù)的邏輯。而且，我們只需要為新的 handler 類添加單元測(cè)試，老的單元測(cè)試都不會(huì)失敗，也不用修改。

?

二. 修改代碼就意味著違背開(kāi)閉原則嗎？

看了上面重構(gòu)之后的代碼，你可能還會(huì)有疑問(wèn)：在添加新的告警邏輯的時(shí)候，盡管改動(dòng)二（添加新的 handler 類）是基于擴(kuò)展而非修改的方式來(lái)完成的，但改動(dòng)一、三、四貌似不是基于擴(kuò)展而是基于修改的方式來(lái)完成的，那改動(dòng)一、三、四不就違背了開(kāi)閉原則嗎？
?

我們回到這條原則的設(shè)計(jì)初衷：只要它沒(méi)有破壞原有的代碼的正常運(yùn)行，沒(méi)有破壞原有的單元測(cè)試，我們就可以說(shuō)，這是一個(gè)合格的代碼改動(dòng)。

?

分析一下改動(dòng)三和改動(dòng)四：這兩處改動(dòng)都是在方法內(nèi)部進(jìn)行的，不管從哪個(gè)層面（模塊、類、方法）來(lái)講，都不能算是“擴(kuò)展”，而是地地道道的“修改”。不過(guò)，有些修改是在所難免的，是可以被接受的。

如果我們把 Alert 類及各個(gè) handler 類合起來(lái)看作一個(gè)“模塊”，那模塊本身在添加新的功能的時(shí)候，完全滿足開(kāi)閉原則。

?
要認(rèn)識(shí)到，添加一個(gè)新功能，不可能任何模塊、類、方法的代碼都不“修改”，這個(gè)是做不到的。類需要?jiǎng)?chuàng)建、組裝、并且做一些初始化操作，才能構(gòu)建成可運(yùn)行的的程序，這部分代碼的修改是在所難免的。
?
我們要做的是盡量讓修改操作更集中、更少、更上層，盡量讓最核心、最復(fù)雜的那部分邏輯代碼滿足開(kāi)閉原則。

?

三. 如何做到“對(duì)擴(kuò)展開(kāi)放、修改關(guān)閉”？

實(shí)際上，開(kāi)閉原則講的就是代碼的擴(kuò)展性問(wèn)題，是判斷一段代碼是否易擴(kuò)展的“金標(biāo)準(zhǔn)”。如果某段代碼在應(yīng)對(duì)未來(lái)需求變化的時(shí)候，能夠做到“對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉”，那就說(shuō)明這段代碼的擴(kuò)展性比較好。

所以，問(wèn)如何才能做到“對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉”，也就粗略地等同于在問(wèn)，如何才能寫出擴(kuò)展性好的代碼。

在講具體的方法論之前，我們先來(lái)看一些更加偏向頂層的指導(dǎo)思想。為了盡量寫出擴(kuò)展性好的代碼，我們要具備擴(kuò)展意識(shí)、抽象意識(shí)、封裝意識(shí)。

支持開(kāi)閉原則的一些更加具體的方法論。

在眾多的設(shè)計(jì)原則、思想、模式中，最常用來(lái)提高代碼擴(kuò)展性的方法有：多態(tài)、依賴注入、基于接口而非實(shí)現(xiàn)編程，以及大部分的設(shè)計(jì)模式（比如，裝飾、策略、模板、職責(zé)鏈、狀態(tài)等）。

如何利用多態(tài)、依賴注入、基于接口而非實(shí)現(xiàn)編程，來(lái)實(shí)現(xiàn)“對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉”。

比如，我們代碼中通過(guò) Kafka 來(lái)發(fā)送異步消息。對(duì)于這樣一個(gè)功能的開(kāi)發(fā)，我們要學(xué)會(huì)將其抽象成一組跟具體消息隊(duì)列（Kafka）無(wú)關(guān)的異步消息接口。 所有上層系統(tǒng)都依賴這組抽象的接口編程，并且通過(guò)依賴注入的方式來(lái)調(diào)用。

當(dāng)我們要替換新的消息隊(duì)列的時(shí)候，比如將 Kafka 替換成 RocketMQ，可以很方便地拔掉老的消息隊(duì)列實(shí)現(xiàn)，插入新的消息隊(duì)列實(shí)現(xiàn)。具體代碼如下所示：

// 這一部分體現(xiàn)了抽象意識(shí)
public interface MessageQueue { //... }
public class KafkaMessageQueue implements MessageQueue { //... }
public class RocketMQMessageQueue implements MessageQueue {//...}

public interface MessageFromatter { //... }
public class JsonMessageFromatter implements MessageFromatter {//...}
public class ProtoBufMessageFromatter implements MessageFromatter {//...}

public class Demo {
  private MessageQueue msgQueue; // 基于接口而非實(shí)現(xiàn)編程
  public Demo(MessageQueue msgQueue) { // 依賴注入
    this.msgQueue = msgQueue;
  }
  
  // msgFormatter：多態(tài)、依賴注入
  public void sendNotification(Notification notification, MessageFormatter msgFormatter) {
    //...    
  }
}

?

四. 如何在項(xiàng)目中靈活應(yīng)用開(kāi)閉原則？

前面我們提到，寫出支持“對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉”的代碼的關(guān)鍵是預(yù)留擴(kuò)展點(diǎn)。那問(wèn)題是如何才能識(shí)別出所有可能的擴(kuò)展點(diǎn)呢？

最合理的做法

• 對(duì)于一些比較確定的、短期內(nèi)可能就會(huì)擴(kuò)展，或者需求改動(dòng)對(duì)代碼結(jié)構(gòu)影響比較大的情況，或者實(shí)現(xiàn)成本不高的擴(kuò)展點(diǎn)，在編寫代碼的時(shí)候之后，我們就可以事先做些擴(kuò)展性設(shè)計(jì)。
• 對(duì)于一些不確定未來(lái)是否要支持的需求，或者實(shí)現(xiàn)起來(lái)比較復(fù)雜的擴(kuò)展點(diǎn)，我們可以等到有需求驅(qū)動(dòng)的時(shí)候，再通過(guò)重構(gòu)代碼的方式來(lái)支持?jǐn)U展的需求。

?

開(kāi)閉原則增加了理解難度

我們之前舉的 Alert 告警的例子。為了更好地支持?jǐn)U展性，我們對(duì)代碼進(jìn)行了重構(gòu)，重構(gòu)之后的代碼要比之前的代碼復(fù)雜很多，理解起來(lái)也更加有難度。

?
需要在擴(kuò)展性和可讀性之間做權(quán)衡

在某些場(chǎng)景下，代碼的擴(kuò)展性很重要，我們就可以適當(dāng)?shù)貭奚恍┐a的可讀性；在另一些場(chǎng)景下，代碼的可讀性更加重要，那我們就適當(dāng)?shù)貭奚恍┐a的可擴(kuò)展性。

在 Alert 告警的例子中，如果告警規(guī)則并不是很多、也不復(fù)雜，那 check() 函數(shù)中的 if 語(yǔ)句就不會(huì)很多，代碼邏輯也不復(fù)雜，代碼行數(shù)也不多，那最初的第一種代碼實(shí)現(xiàn)思路簡(jiǎn)單易讀，就是比較合理的選擇。

相反，如果告警規(guī)則很多、很復(fù)雜，check() 函數(shù)的 if 語(yǔ)句、代碼邏輯就會(huì)很多、很復(fù)雜，相應(yīng)的代碼行數(shù)也會(huì)很多，可讀性、可維護(hù)性就會(huì)變差，那重構(gòu)之后的第二種代碼實(shí)現(xiàn)思路就是更加合理的選擇了。

?

參考：《設(shè)計(jì)模式之美》–王爭(zhēng)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-824727.html

到了這里，關(guān)于【設(shè)計(jì)模式之美】SOLID 原則之二：開(kāi)閉原則方法論、開(kāi)閉原則如何取舍的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！