第一章、面向?qū)ο笪宕蠡驹瓌t SOLID原則

1.1 單一職責(zé)

參考：http://www.reibang.com/p/63bd557f6ca4
單一職責(zé)原則的英文是 Single Responsibility Principle，縮寫(xiě)為 SRP。他的英文描述是:A class or module should have a single reponsibility砰嘁。翻譯過(guò)來(lái)就是：一個(gè)類或者模塊只負(fù)責(zé)完成一個(gè)職責(zé)（或者功能）遂蛀。

意思是一個(gè)類只負(fù)責(zé)完成一個(gè)職責(zé)或者功能撬碟。也就是說(shuō)图甜，不要設(shè)計(jì)大而全的類，要設(shè)計(jì)粒度小囚灼、功能單一的類骆膝。換個(gè)角度來(lái)講就是，一個(gè)類包含了兩個(gè)或者兩個(gè)以上業(yè)務(wù)不相干的功能灶体，那我們就說(shuō)它職責(zé)不夠單一谭网，應(yīng)該將它拆分成多個(gè)功能更加單一、粒度更細(xì)的類赃春。

這個(gè)原則看似比較簡(jiǎn)單，但實(shí)際在開(kāi)發(fā)中判斷一個(gè)類是否單一是比較難拿捏的劫乱。因?yàn)樵诓煌膽?yīng)用場(chǎng)景和業(yè)務(wù)的不同階段织中，對(duì)同一個(gè)類職責(zé)判斷是否單一都是有可能不一樣的。在當(dāng)前需求下一個(gè)類可能已經(jīng)滿足了單一職責(zé)的判斷衷戈，但如果換一個(gè)應(yīng)用場(chǎng)景或者未來(lái)的某個(gè)需求背景下可能就不滿足了狭吼，需要繼續(xù)拆分成粒度更細(xì)的類。所以通常我們可以先寫(xiě)一個(gè)粗粒度的類殖妇，滿足業(yè)務(wù)需求刁笙。隨著業(yè)務(wù)的發(fā)展如果粗粒度的類越來(lái)越龐大的時(shí)候，我們?cè)賹⑦@個(gè)粗粒度的類拆分成幾個(gè)更細(xì)粒度的類。

判斷一個(gè)類是否需要拆分有以下幾個(gè)原則供參考：

• 類中的代碼行數(shù)疲吸、函數(shù)或?qū)傩赃^(guò)多座每，會(huì)影響代碼的可讀性和可維護(hù)性，我們就需要考慮對(duì)類進(jìn)行拆分摘悴；
• 類依賴的其他類過(guò)多峭梳，或者依賴類的其他類過(guò)多，不符合高內(nèi)聚蹂喻、低耦合的設(shè)計(jì)思想葱椭，我們就需要考慮對(duì)類進(jìn)行拆分；
• 私有方法過(guò)多口四，我們就要考慮能否將私有方法獨(dú)立到新的類中孵运，設(shè)置為 public 方法，供更多的類使用蔓彩，從而提高代碼的復(fù)用性治笨；
• 比較難給類起一個(gè)合適名字，很難用一個(gè)業(yè)務(wù)名詞概括粪小，或者只能用一些籠統(tǒng)的 Manager大磺、Context 之類的詞語(yǔ)來(lái)命名，這就說(shuō)明類的職責(zé)定義得可能不夠清晰探膊；
• 類中大量的方法都是集中操作類中的某幾個(gè)屬性杠愧，那就可以考慮將這幾個(gè)屬性和對(duì)應(yīng)的方法拆分出來(lái)。

1.2 開(kāi)閉原則

開(kāi)閉原則的英文全稱是 Open Closed Principle逞壁，簡(jiǎn)寫(xiě)為 OCP流济。它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。翻譯過(guò)來(lái)就是：軟件實(shí)體（模塊腌闯、類绳瘟、方法等）應(yīng)該“對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉”姿骏。

這個(gè)描述比較簡(jiǎn)略糖声，詳細(xì)表述一下就是：添加一個(gè)新的功能應(yīng)該是在已有代碼基礎(chǔ)上擴(kuò)展代碼（新增模塊、類分瘦、方法等）蘸泻，而非修改已有代碼（修改模塊、類嘲玫、方法等）悦施。

這里說(shuō)的不修改已有代碼并不是指完全杜絕修改代碼，在軟件開(kāi)發(fā)需求迭代中修改代碼是在所難免的去团，我們要做的是盡量讓修改操作更集中抡诞、更少穷蛹、更上層，盡量讓最核心昼汗、最復(fù)雜的那部分邏輯代碼滿足開(kāi)閉原則肴熏。

打個(gè)比方說(shuō)，有一個(gè)插入用戶信息：姓名乔遮，年齡扮超，電話的方法。

class Demo{
      public void insertUserInfo(String name,int age,String tel){
          ....
      }

}

如果隨著業(yè)務(wù)的發(fā)展這個(gè)方法需要把用戶的email也插入進(jìn)去蹋肮，如果我們直接修改這個(gè)方法添加一個(gè)email參數(shù)

class Demo{
      public void insertUserInfo(String name,int age,String tel,String email){
          ....
      }

}

這樣的修改就有違背開(kāi)閉原則出刷，代碼上所有調(diào)用這個(gè)方法的地方都需要修改。

假如是這樣的代碼

class Demo{
      public void insert(User user){
          ....
      }

}

class User{
    String name;
    int age;
    String tel;
}

我們?yōu)榱藵M足業(yè)務(wù)的需求坯辩，需要在插入用戶信息的時(shí)候把email也插入進(jìn)去馁龟，那么我們直接在User類中添加一個(gè)email屬性，這樣的修改就沒(méi)有違背開(kāi)閉原則漆魔。

其實(shí)也可以這樣理解坷檩，開(kāi)閉原則說(shuō)的是軟件實(shí)體（模塊、類改抡、方法等）應(yīng)該“對(duì)擴(kuò)展開(kāi)放矢炼、對(duì)修改關(guān)閉”。我們可以看出來(lái)阿纤，開(kāi)閉原則可以應(yīng)用在不同粒度的代碼中句灌，可以是模塊，也可以類欠拾，還可以是方法（及其屬性）胰锌。同樣一個(gè)代碼改動(dòng)褥伴，在粗代碼粒度下雷滋，被認(rèn)定為“修改”漱竖，在細(xì)代碼粒度下岗仑，又可以被認(rèn)定為“擴(kuò)展”。比如既穆，添加屬性和方法相當(dāng)于修改類准脂，在類這個(gè)層面饿悬，這個(gè)代碼改動(dòng)可以被認(rèn)定為“修改”刹枉；但這個(gè)代碼改動(dòng)并沒(méi)有修改已有的屬性和方法叽唱，在方法（及其屬性）這一層面，它又可以被認(rèn)定為“擴(kuò)展”嘶卧。

再則我們通過(guò)上面滿足同一需求的方法代碼來(lái)看，下面那個(gè)傳User對(duì)象的方法比上面的方法更方便擴(kuò)展一些凉袱，這也就是為什么要遵循開(kāi)閉原則來(lái)寫(xiě)代碼的原因芥吟。

1.3 里式替換原則

里式替換原則的英文翻譯是：Liskov Substitution Principle侦铜，縮寫(xiě)為 LSP。這個(gè)原則最早是在 1986 年由 Barbara Liskov 提出钟鸵，他是這么描述這條原則的：

If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program钉稍。

在 1996 年，Robert Martin 在他的 SOLID 原則中棺耍，重新描述了這個(gè)原則贡未，英文原話是這樣的：

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。

綜合兩者的描述蒙袍，將這條原則用中文描述出來(lái)俊卤，是這樣的：子類對(duì)象（object of subtype/derived class）能夠替換程序（program）中父類對(duì)象（object of base/parent class）出現(xiàn)的任何地方，并且保證原來(lái)程序的邏輯行為（behavior）不變及正確性不被破壞害幅。

原則里說(shuō)“子類替換父類出現(xiàn)的地方”咋一看有點(diǎn)像面向?qū)ο罄锒鄳B(tài)的意思消恍，其實(shí)不是。多態(tài)是面向?qū)ο缶幊痰囊淮筇匦砸韵郑彩敲嫦驅(qū)ο缶幊陶Z(yǔ)言的一種語(yǔ)法狠怨。它是一種代碼實(shí)現(xiàn)的思路。而里式替換是一種設(shè)計(jì)原則邑遏，是用來(lái)指導(dǎo)繼承關(guān)系中子類該如何設(shè)計(jì)的佣赖，子類的設(shè)計(jì)要保證在替換父類的時(shí)候，不改變?cè)谐绦虻倪壿嬕约安黄茐脑谐绦虻恼_性记盒。直接來(lái)講就是按照協(xié)議來(lái)設(shè)計(jì)憎蛤。

舉個(gè)例子

class SecurityService{

    public boolean isRightfulPassword(String password){
          if(password==null || password.length < 6){
                return false;
          }
          return true;
    }
}

class SonSecurityService extends SecurityService{
     @Override
     public boolean isRightfulPassword(String password){
          if(password==null){
               throw new ParameterNullRunTimeException();
          }
          return super.isRightfulPassword(password);
    }
}

在父類SecurityService中isRightfulPassword參數(shù)password為空的時(shí)候返回的結(jié)果是false，而子類SonSecurityService在替換父類后孽鸡，當(dāng)password為空時(shí)卻拋了一個(gè)異常蹂午，這就違背了里式替換原則。

里式替換原則是用來(lái)指導(dǎo)繼承關(guān)系中子類該如何設(shè)計(jì)的一個(gè)原則彬碱。理解里式替換原則豆胸，最核心的就是理解“按照協(xié)議來(lái)設(shè)計(jì)（design by contract）”。父類定義了函數(shù)的“約定”（或者叫協(xié)議）巷疼，那子類可以改變函數(shù)的內(nèi)部實(shí)現(xiàn)邏輯晚胡，但不能改變函數(shù)原有的“約定”。這里的約定包括：函數(shù)聲明要實(shí)現(xiàn)的功能嚼沿；對(duì)輸入估盘、輸出、異常的約定骡尽；業(yè)務(wù)上的特殊限制遣妥；

有一個(gè)比較簡(jiǎn)單的方法來(lái)判斷是否違背了里式替換原則。那就是拿父類的單元測(cè)試去驗(yàn)證子類的代碼攀细。如果某些單元測(cè)試運(yùn)行失敗箫踩，就有可能說(shuō)明爱态，子類有可能違背了里式替換原則。

1.4 接口隔離原則

接口隔離原則的英文翻譯是“ Interface Segregation Principle”境钟，縮寫(xiě)為 ISP锦担。Robert Martin 在 SOLID 原則中是這樣定義它的：“Clients should not be forced to depend upon interfaces that they do not use】鳎”直譯成中文的話就是：客戶端不應(yīng)該強(qiáng)迫依賴它不需要的接口洞渔。其中的“客戶端”，可以理解為接口的調(diào)用者或者使用者缚态。

舉個(gè)例子：

public interface UserService {
      //注冊(cè)
      boolean register(String username, String password);
      //登錄
      boolean login(String username, String password);
      //查詢用戶
      User getUserById(int id);
     //刪除用戶
      boolean deleteUserById(int id);
}

有一個(gè)用戶服務(wù)的接口磁椒，里面有注冊(cè)，登錄猿规，查詢衷快，刪除幾個(gè)函數(shù)暴露給客戶端，但是很明顯刪除函數(shù)只有后臺(tái)管理模塊可以用到姨俩，而且其他模塊如果都可以使用的話就有可能照成誤刪用戶蘸拔。這就違背了接口隔離原則，我們需要把刪除函數(shù)單獨(dú)抽離出來(lái)給后臺(tái)管理模塊使用环葵。

public interface UserService {
      //注冊(cè)
      boolean register(String username, String password);
      //登錄
      boolean login(String username, String password);
      //查詢用戶
      User getUserById(int id);
      
}

public interface AdminUserService {
        //刪除用戶
      boolean deleteUserById(int id);
}

其中“接口”也可以有不同的含義：

• 可以把它理解為微服務(wù)的一組接口调窍，如果部分接口只被部分調(diào)用者使用，我們就需要將這部分接口隔離出來(lái)张遭，單獨(dú)給這部分調(diào)用者使用邓萨，而不強(qiáng)迫其他調(diào)用者也依賴這部分不會(huì)被用到的接口；
• 可以把它理解成api接口或者函數(shù)菊卷，部分調(diào)用者只需要函數(shù)中的部分功能缔恳，那我們就需要把函數(shù)拆分成粒度更細(xì)的多個(gè)函數(shù)，讓調(diào)用者只依賴它需要的那個(gè)細(xì)粒度函數(shù)洁闰。
• 可以把它理解成面向?qū)ο缶幊讨卸x的接口語(yǔ)法歉甚，那接口的設(shè)計(jì)要盡量單一，不要讓接口的實(shí)現(xiàn)類和調(diào)用者扑眉，依賴不需要的接口函數(shù)纸泄。

說(shuō)起接口隔離其實(shí)和單一原則比較類似，都是指在代碼設(shè)計(jì)上盡量單一腰素。不同的是單一原則針對(duì)的是模塊聘裁，類，接口的設(shè)計(jì)弓千。接口隔離原則不光說(shuō)的是接口的設(shè)計(jì)衡便，還提供了一種判斷接口職責(zé)是否單一的標(biāo)準(zhǔn)：如果調(diào)用者只使用部分接口或接口的部分功能，那接口的設(shè)計(jì)就不夠職責(zé)單一。

1.5 依賴倒置原則(Dependence Inversion Principle ,DIP)

參考：http://www.reibang.com/p/377830cb1112

定義：
①高級(jí)模塊不應(yīng)該依賴于低級(jí)模塊镣陕，兩者都應(yīng)該依賴于抽象征唬。
②抽象不應(yīng)該依賴于細(xì)節(jié)。
③細(xì)節(jié)應(yīng)該依賴于抽象茁彭。

那么高級(jí)模塊、低級(jí)模塊扶歪，抽象理肺，細(xì)節(jié)各指的是什么呢？
每一個(gè)邏輯的實(shí)現(xiàn)都是由原子邏輯組成善镰，不可分割的原子邏輯就是低級(jí)模塊妹萨。而低級(jí)模塊組裝就是高級(jí)模塊。
在Java中炫欺，抽象就是指接口或抽象類乎完，兩者并不能直接被實(shí)例化。
細(xì)節(jié)就是實(shí)現(xiàn)類品洛，繼承抽象類或?qū)崿F(xiàn)接口的類就是細(xì)節(jié)树姨。特點(diǎn)是可以被直接實(shí)例化。

那么依賴倒置原則定義在Java語(yǔ)言中可以表示為：
①模塊間的依賴關(guān)系桥状、實(shí)現(xiàn)類間的依賴關(guān)系都是通過(guò)接口或抽象類產(chǎn)生帽揪。
②接口與抽象類不依賴實(shí)現(xiàn)類。
③實(shí)現(xiàn)類依賴接口或抽象辅斟。
從上述定義我們可以看出转晰，依賴倒置原則的核心思想就是：面向接口編程

代碼重現(xiàn)：

司機(jī)類

public class Driver {
   public void drive(Benz benz){
      benz.run();
   }
}

奔馳類

public class Benz {
   public void run(){
      System.out.println("開(kāi)奔馳車(chē)上路");
   }
}

測(cè)試類

public class Demo_01 {
   public static void main(String[] args) {
         Driver sanmao = new Driver();
         sanmao.drive(new Benz());
   }
}
--------------------output---------------------------
開(kāi)奔馳車(chē)上路

通過(guò)以上代碼完成了司機(jī)類開(kāi)奔馳車(chē)的場(chǎng)景。
但是隨著業(yè)務(wù)需求的變更士飒，現(xiàn)在要求這個(gè)司機(jī)還能開(kāi)寶馬車(chē)查邢，那么上面代碼必須要重寫(xiě)（耦合性太強(qiáng)），才能滿足業(yè)務(wù)需求酵幕，顯然上面代碼在設(shè)計(jì)上有錯(cuò)誤扰藕。
那么我們依據(jù)依賴倒置原則重構(gòu)以上代碼：

司機(jī)接口類

public interface IDriver {
    void drive(ICar iCar);
}

司機(jī)實(shí)現(xiàn)類

public class Driver implements IDriver{
   @Override
   public void drive(ICar iCar) {
      iCar.run();
   }
}

汽車(chē)接口類

public interface ICar {
    void run();
}

汽車(chē)實(shí)現(xiàn)類

public class Benz implements ICar{
   @Override
   public void run() {
      System.out.println("開(kāi)奔馳上路");
   }
}
public class BMW implements ICar {
   @Override
   public void run() {
      System.out.println("開(kāi)寶馬上路");
   }
}

測(cè)試類

public class Demo_01 {
   public static void main(String[] args) {
    IDriver sanmao = new Driver();
    ICar benz = new Benz();
    ICar BMW = new BMW();
    sanmao.drive(benz);
    sanmao.drive(BMW);
   }
}
--------------------output---------------------------
開(kāi)奔馳上路
開(kāi)寶馬上路

Demo_01類就是高級(jí)模塊，他對(duì)所有低級(jí)模塊的依賴都建立在抽象類或接口上

在IDriver接口中傳入ICar接口裙盾，實(shí)現(xiàn)模塊間的依賴關(guān)系是通過(guò)接口或抽象類產(chǎn)生实胸。在Driver實(shí)現(xiàn)類中也傳入了ICar接口，究竟使用Car的哪個(gè)子類還得在測(cè)試類中聲明番官。
在測(cè)試類中庐完，我們貫徹“②接口與抽象類不依賴實(shí)現(xiàn)類∨侨郏”门躯，所以在測(cè)試類Demo_01中，我們都是聲明了各類的抽象酷师。

注意：在Java中讶凉，只要定義變量就必然要有類型染乌。一個(gè)變量可以有兩種類型：表面類型與實(shí)際類型。表面類型是在定義時(shí)賦予的類型懂讯，實(shí)際類型是對(duì)象的類型荷憋，如sanmao的表現(xiàn)類型是IDriver，實(shí)際類型為Driver褐望。

依賴的三種寫(xiě)法
依賴是可以傳遞的勒庄。A對(duì)象依賴B對(duì)象，B依賴C瘫里，C依賴D...实蔽，
只要做到抽象依賴，即使是多層的依賴傳遞也無(wú)所畏懼谨读。
對(duì)象的依賴關(guān)系有以下三種方式傳遞局装，可以參考Spring的依賴注入

①構(gòu)造函數(shù)傳遞依賴關(guān)系

public interface IDriver {
    void drive();
}

public class Driver implements IDriver{
   private ICar iCar;
   public Driver(ICar _iCar){
      this.iCar = _iCar;
   }
   
   public void drive() {
      this.iCar.run();
   }
}

②Setter方法傳遞依賴關(guān)系

public interface IDriver {
    void drive();
    void setCar(ICar _iCar);
}

public class Driver implements IDriver{
   private ICar iCar;
   @Override
   public void drive() {
      this.iCar.run();
   }
   @Override
   public void setCar(ICar _iCar) {
      this.iCar = _iCar;
   }
}

③接口聲明依賴關(guān)系

public interface IDriver {
    void drive(ICar iCar);
}

public class Driver implements IDriver{
   @Override
   public void drive(ICar iCar) {
      iCar.run();
   }
}

依賴倒置原則的本質(zhì)就是通過(guò)接口或抽象類使得各模塊間相互獨(dú)立，互不影響劳殖，實(shí)現(xiàn)松耦合铐尚。在使用這個(gè)原則時(shí)，我們需要注意以下幾個(gè)原則：

①每個(gè)類都盡可能的都有接口或抽象類哆姻，或者抽象類和接口兩者都具備塑径。（依賴倒置原則的基本要求）
②變量的表面類型盡量是接口或者抽象類。（工具類不需要接口或者抽象類填具，使用類的Clone方法统舀，必須使用實(shí)現(xiàn)類，這是JDK的規(guī)范）
③任何類都不應(yīng)該從具體類派生劳景。
④盡量不要覆寫(xiě)基類的方法誉简。（若基類是一個(gè)抽象類，此方法已經(jīng)實(shí)現(xiàn)盟广，那么子類就不應(yīng)該覆寫(xiě)）
⑤結(jié)合里氏替換原則使用
接口負(fù)責(zé)public屬性與方法闷串，并且聲明與其他對(duì)象的依賴關(guān)系，抽象類負(fù)責(zé)公共構(gòu)造部分的實(shí)現(xiàn)筋量，實(shí)現(xiàn)類準(zhǔn)確的實(shí)現(xiàn)業(yè)務(wù)邏輯烹吵，同時(shí)在適當(dāng)?shù)臅r(shí)候?qū)Ω割愡M(jìn)行細(xì)化。

上面講完了依賴關(guān)系與原則桨武，那么什么叫倒置呢肋拔？
要理解倒置，首先我們得知道什么叫“正置”呀酸。依賴正置就是類之間的依賴是實(shí)現(xiàn)類間的依賴凉蜂，也就是面向?qū)崿F(xiàn)編程。但是編寫(xiě)程序需要的是對(duì)現(xiàn)實(shí)世界的事物進(jìn)行抽象，轉(zhuǎn)化為我們熟知的抽象類或接口窿吩，這樣我們就可以將模塊間的依賴關(guān)系茎杂、實(shí)現(xiàn)類間的依賴關(guān)系都是通過(guò)接口或抽象類產(chǎn)生。這就是我們所說(shuō)的“倒置”纫雁。