盡管大家都認為SOLID是非常重要的設計原則，并且對每一條原則都耳熟能詳，但我發現大部分開發者并沒有真正理解。要獲得***收益，就必須理解它們之間的關系，并綜合應用所有這些原則。只有把SOLID作為一個整體，才可能構建出堅實(Solid)的軟件。遺憾的是，我們看到的書籍和文章都在羅列每個原則，沒有把它們作為一個整體來看，甚至提出SOLID原則的Bob大叔也沒能講透徹。因此我嘗試介紹一下我的理解。

先拋出我的觀點: 單一職責是所有設計原則的基礎，開閉原則是設計的***目標。里氏替換原則強調的是子類替換父類后程序運行時的正確性，它用來幫助實現開閉原則。而接口隔離原則用來幫助實現里氏替換原則，同時它也體現了單一職責。依賴倒置原則是過程式編程與OO編程的分水嶺，同時它也被用來指導接口隔離原則。關系如下圖：

單一職責原則(Single Responsibility Principle, SRP)

單一職責是最容易理解的設計原則，但也是被違反得最多的設計原則之一。

要真正理解并正確運用單一職責原則，并沒有那么容易。單一職責就跟“鹽少許”一樣，不好把握。Robert C. Martin(又名“Bob大叔”)把職責定義為變化原因，將單一職責描述為 ”A class should have only one reason to change." 也就是說，如果有多種變化原因導致一個類要修改，那么這個類就違反了單一職責原則。那么問題來了，什么是“變化原因”呢?

利益相關者角色是一個重要的變化原因，不同的角色會有不同的需求，從而產生不同的變化原因。作為居民，家用的電線是普通的220V電線，而對電網建設者，使用的是高壓電線。用一個Wire類同時服務于兩類角色，通常意味著壞味道。

變更頻率是另一個值得考慮的變化原因。即使對同一類角色，需求變更的頻率也會存在差異。最典型的例子是業務處理的需求比較穩定，而業務展示的需求更容易發生變更，畢竟人總是喜新厭舊的。因此這兩類需求通常要在不同的類中實現。

單一職責原則某種程度上說是在分離關注點。分離不同角色的關注點，分離不同時間的關注點。

在實踐中，怎么運用單一職責原則呢?什么時候要拆分，什么時候要合并?我們看看新廚師在學炒菜時，是如何掌握“鹽少許”的。他會不斷地品嘗，直到味道剛好為止。寫代碼也一樣，你需要識別需求變化的信號，不斷“品嘗”你的代碼，當“味道”不夠好時，持續重構，直到“味道”剛剛好。

開閉原則(Open-closed Principle)

開閉原則指軟件實體(類、模塊等)應當對擴展開放，對修改閉合。這聽起來似乎很不合理，不能修改，只能擴展?那我怎么寫代碼?

我們先看看為什么要有開閉原則。假設你是一名成功的開源類庫作者，很多開發者使用你的類庫。如果某天你要擴展功能，只能通過修改某些代碼完成，結果導致類庫的使用者都需要修改代碼。更可怕的是，他們被迫修改了代碼后，又可能造成別的依賴者也被迫修改代碼。這種場景絕對是一場災難。

如果你的設計是滿足開閉原則的，那就完全是另一種場景。你可以通過擴展，而不是修改來改變軟件的行為，將對依賴方的影響降到***。

這不正是設計的***目標嗎?解耦、高內聚、低耦合等等設計原則最終不都是為了這個目標嗎?暢想一下，類、模塊、服務都不需要修改，而是通過擴展就能夠改變其行為。就像計算機一樣，組件可以輕松擴展。硬盤太小?直接換個大的，顯示器不夠大的?來個8K的怎么樣?

[[245290]]

什么時候應該應用開閉原則，怎么做到呢?沒有人能夠在一開始就識別出所有擴展點，也不可能在所有地方都預留出擴展點，這么做的成本是不可接受的。因此一定是由需求變化驅動。如果你有領域專家的支持，他可以幫你識別出變化點。否則，你應該在變化發生時來做決策，因為在沒有任何依據時做過多預先設計違反了Yagni。

實現開閉原則的關鍵是抽象。在Bertrand Meyer提出開閉原則的年代(上世紀80年代)，在類庫中增加屬性或方法，都不可避免地要修改依賴此類庫的代碼。這顯然導致軟件很難維護，因此他強調的是要允許通過繼承來擴展類。隨著技術發展，我們有了更多的方法來實現開閉原則，包括接口、抽象類、策略模式等。

我們也許永遠都無法完全做到開閉原則，但不妨礙它是設計的***目標。SOLID的其它原則都直接或間接為開閉原則服務，例如接下來要介紹的里氏替換原則。

里氏替換原則 (The Liskov Substitution Principle)

里氏替換原則說的是派生類(子類)對象能夠替換其基類(父類)對象被使用。學過OO的同學都知道，子類本來就可以替換父類，為什么還要里氏替換原則呢?這里強調的不是編譯錯誤，而是程序運行時的正確性。

程序運行的正確性通常可以分為兩類。一類是不能出現運行時異常，最典型的是UnsupportedOperationException，也就是子類不支持父類的方法。第二類是業務的正確性，這取決于業務上下文。

下例中，由于java.sql.Date不支持父類的toInstance方法，當父類被它替換時，程序無法正常運行，破壞了父類與調用方的契約，因此違反了里氏替換原則。

package java.sql; 
 
public class Date extends java.util.Date { 
  @Override 
  public Instant toInstant() { 
    throw new java.lang.UnsupportedOperationException(); 
  } 
}   

接下來我們看破壞業務正確性的例子，最典型的例子就是Bob大叔在《敏捷軟件開發：原則、模式與實踐》中講到的正方形繼承矩形的例子了。從一般意義來看，正方形是一種矩形，但這種繼承關系破壞了業務的正確性。

public class Rectangle { 
  double width; 
  double height; 
   
  public double area() { 
    return width * height; 
  } 
} 
 
public class Square extends Rectangle { 
  public void setWidth(double width) { 
    this.width = width; 
    this.height = width; 
  } 
   
  public void setHeight(double height) {  
    this.height = width; 
    this.width = width; 
   } 
 } 
  
 public void testArea(Rectangle r) {  
   r.setWidth(5); 
   r.setHeight(4);   
   assert(r.area() == 20); //! 如果r是一個正方形，則面積為16 
} 

代碼中testArea方法的參數如果是正方形，則面積是16，而不是期望的20，所以結果顯然不正確了。

如果你的設計滿足里氏替換原則，那么子類(或接口的實現類)就可以保證正確性的前提下替換父類(或接口)，改變系統的行為，從而實現擴展。BranchByAbstraction和絞殺者模式都是基于里氏替換原則，實現系統擴展和演進。這也就是對修改封閉，對擴展開放，因此里氏替換原則是實現開閉原則的一種解決方案。

而為了達成里氏替換原則，你需要接口隔離原則。

接口隔離原則 (Interface Segregation Principle)

接口隔離原則說的是客戶端不應該被迫依賴于它不使用的方法。簡單來說就是更小和更具體的瘦接口比龐大臃腫的胖接口好。

胖接口的職責過多，很容易違反單一職責原則，也會導致實現類不得不拋出UnsupportedOperationException這樣的異常，違反里氏替換原則。因此，應該將接口設計得更瘦。

怎么給接口減肥呢?接口之所以存在，是為了解耦。開發者常常有一個錯誤的認知，以為是實現類需要接口。其實是消費者需要接口，實現類只是提供服務，因此應該由消費者(客戶端)來定義接口。理解了這一點，才能正確地站在消費者的角度定義Role interface，而不是從實現類中提取Header Interface。

什么是Role interface? 舉個例子，磚頭(Brick)可以被建筑工人用來蓋房子，也可以被用來正當防衛：

public class Brick { 
  private int length; 
  private int width; 
  private int height; 
  private int weight; 
   
  public void build() { 
    //...包工隊蓋房 
  } 
   
  public void defense() { 
    //...正當防衛 
  } 
} 

如果直接提取以下接口，這就是Header Interface：

public interface BrickInterface { 
  void buildHouse(); 
  void defense(); 
} 

普通大眾需要的是可以防衛的武器，并不需要用磚蓋房子。當普通大眾(Person)被迫依賴了自己不需要的接口方法時，就違反接口隔離原則。正確的做法是站在消費者的角度，抽象出Role interface:

public interface BuildHouse { 
  void build(); 
} 
public interface StrickCompetence { 
  void defense(); 
} 
 
public class Brick implement BuildHouse, StrickCompetence { 
} 

有了Role interface，作為消費者的普通大眾和建筑工人就可以分別消費自己的接口：

Worker.java 
brick.build(); 
 
Person.java 
brick.strike(); 

接口隔離原則本質上也是單一職責原則的體現，同時它也服務于里氏替換原則。而接下來介紹的依賴倒置原則可以用來指導接口隔離原則的實現。

依賴倒置原則 (Dependence Inversion Principle)

依賴倒置原則說的是高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象。

這個原則其實是在指導如何實現接口隔離原則，也就是前文提到的，高層的消費者不應該依賴于具體實現，應該由消費者定義并依賴于Role interface，底層的具體實現也依賴于Role interface，因為它要實現此接口。

依賴倒置原則是區分過程式編程和面向對象編程的分水嶺。過程式編程的依賴沒有倒置，A Simple DIP Example | Agile Principles, Patterns, and Practices in C#這篇文章以開關和燈的例子很好地說明了這一點。

上圖的關系中，當Button直接調用燈的開和關時，Button就依賴于燈了。其代碼完全是過程式編程：

public class Button {  
  private Lamp lamp;  
  public void Poll()   { 
    if (/*some condition*/) 
      lamp.TurnOn();  
  } 
} 

如果Button還想控制電視機，微波爐怎么辦?應對這種變化的辦法就是抽象，抽象出Role interface ButtonServer:

不管是電燈，還是電視機，只要實現了ButtonServer，Button都可以控制。這是面向對象的編程方式。

總結

總的來說，單獨應用SOLID的某一個原則并不能讓收益***化。應該把它作為一個整體來理解和應用，從而更好地指導你的軟件設計。單一職責是所有設計原則的基礎，開閉原則是設計的***目標。里氏替換原則強調的是子類替換父類后程序運行時的正確性，它用來幫助實現開閉原則。而接口隔離原則用來幫助實現里氏替換原則，同時它也體現了單一職責。依賴倒置原則是過程式編程與OO編程的分水嶺，同時它也被用來指導接口隔離原則。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文