第10章 Liskov 替換原則（LSP）

原則解釋：

子類型（sbutype）必須能夠替換掉它們的基類型（base type）

這一章沒大看懂，貌似和 OCP（開發關閉原則）關系很大，以後再研究

第11章 依賴倒置原則（DIP）

原則解釋：

a. 高層模塊不應該依賴於低層模塊。二者都應該依賴於抽象。

b. 抽象不應該依賴於細節。細節應該依賴於抽象。

“請註意這個規則裏的倒置不僅僅是依賴關系的倒置，它也是接口所有權的倒置。我們通常會認為工具庫應該擁有它們自己的接口。但是當應用了 DIP 時，我們發現往往是客戶擁有抽象接口，而它們的服務者則從這些抽象接口派生。”

這裏談下我自己對這段話的理解：

由於在平常的開發中，我接觸到的以及我自己使用的方式都是，將接口和對應實體類的名字起的相似（後者在前者的名字後加上 impl），所以自然而然地就會認為它們倆是一體的，即“工具庫擁有它們自己的接口”

而仔細想一下的話，會發現，其實被調用方存在的意義是：調用方有相關的需求，即調用方需要一些東西，然後說明了自己需要什麽樣的東西（制定規則），然後被調用方才按照這些規則去做相關的實現。（可以參考實際工作中：正是因為有了需求，技術才有存在的意義）

即，規則的擁有者和制定者從來都是調用方，而不是被調用方

這裏可以聯想一下 JDBC 相關知識，我們知道，JDBC 自己制定了規範，然後使用 JDBC 操作數據庫的用戶就可以不必理會數據庫具體的實現細節了，他們只需要調用 JDBC 規定好的那些接口就行了（屏蔽了實現細節）

而在 Java 和 數據庫廠商 之間，誰擁有主動權？

是 Java

由於 Java 良好的特性，Java 的市場非常的廣泛，並且在未來的使用規模也非常可期

由於這一點，和 Java 合作的話，會獲取到非常大的市場空間

所以，從商業角度來說，數據庫廠商看到這一趨勢之後，必定會迎合 Java 的規範

這時，擁有了話語權的 Java（可以看做甲方） 必定會站在自己的角度，制定一套規範，讓使用 Java 的開發人員只需要面對這個規範操作數據庫（因為在無需關註數據庫相關實現細節的情況下，開發人員會省去很多精力，這樣一來，Java 受到更多的開發人員歡迎）

在這個例子中，Java 可以被認為是調用方，數據庫可以被認為是被調用方，JDBC 規範可以被認為是抽象接口

很顯然，JDBC 不是數據庫對外暴露的接口規範，而是 Java 作為調用方站在自己的角度，制定的一套規範

理解了接口所有權的歸屬問題之後，就能理解這個原則的名字為什麽叫“依賴倒置”了

畫圖說明

一般的面向過程編程中，高層對低層的依賴關系如下：

A 所在模塊被稱為高層模塊，B 所在模塊被稱為低層模塊，則在此關系中，高層模塊直接依賴於低層模塊

當使用接口作為中間人時，如果這麽理解

認為接口（b）所有權歸被調用方（B）所有

則依賴關系如下圖：

即，還是 A 所在的高層模塊在依賴 B 所在的低層模塊，並沒有發生所謂的依賴“倒置”

但是，但我們換一個理解方式，即

認為接口（b）所有權歸調用方（A）所有

則依賴關系如下圖：

顯然，這樣理解的話，可以很明顯的看出，依賴關系被“倒置”了，因為在此圖中，A 所在的模塊被 B 所在的模塊所依賴

更高階的操作（或者說更高階的理解）

即，接口沒有所有者，它自己獨立於被調用方和調用方，成為了第三個模塊

具體可見可見書中 11.3 小節最後幾段的敘述

回到上述我畫的幾個圖中，由於 b 和 B 的關系互為大小寫，所以會對這種理解造成阻礙，所以，把 b 換成另外一個名字，再重新畫一張依賴圖：

是否可以按照這個思路理解 Spring 的 IOC 容器呢？即，按照那個流傳的說法：調用方和被調用方解耦，它們都依賴於第三方容器

看完這一章的內容，才大概明白一直被吹捧的 Spring 牛在哪裏，以及為什麽 IOC 是 Spring 的核心之一

同時，結合 Spring，也能更理解書中的一些描述：

“如果高層模塊獨立於底層模塊，那麽高層模塊就可以非常容易地被重用。該原則（指依賴倒置原則）是框架設計的核心原則”

“使用傳統的過程化的程序設計所創建出來的依賴關系結構，策略是依賴於細節的。這是糟糕的，因為這樣會使策略收到細節改變的影響。面向對象的程序設計倒置了依賴關系結構，使得細節和策略都依賴於抽象，並且常常是客戶擁有服務接口”

“事實上，這種依賴關系的倒置正是好的面向對象設計的標誌所在。使用何種語言來編寫程序是無關緊要的。如果程序的依賴關系是倒置的，它就是面向對象的設計。如果程序的依賴關系不是倒置的，它就是過程化的設計”

“依賴倒置原則是實現許多面向對象技術所宣稱的好處的基本低層機制。它的正確應用對於創建可重用的框架來說是必須的。同時它對於構建在變化面前富有彈性的代碼也是非常重要的。由於抽象和細節被彼此隔離，所以代碼也非常容易維護。”

個人感悟：

關於經典的原則和設計思想，如果想要深入理解的話，最好直接找到對應的經典書籍查看，而不是在網上找一堆博客看，一來很多博主自己都沒有理解清楚，二來，就算博主理解清楚了，也不一定有與那些能寫出經典書籍的大師相當的表達能力

如果哪位朋友碰巧看了本文，那麽推薦你看看《敏捷軟件開發 原則、模式與實踐》這本書，書名講的是敏捷開發，其實裏面的內容是面向對象設計的原則和模式，認真看了本書，可以帶你進入 OOP 的大門（套用劉大的話，哈哈）。

第12章 接口隔離原則（ISP）

原則解釋：

不應該強迫客戶依賴於它們不使用的方法

只看了一小部分，大概的理解是：

接口或類中的所有方法，如果可以被更進一步地分組，則應該將它們放置於不同的類或接口中，而不應該籠統地放到同一個類或接口中

敏捷軟件開發 第十章、第十一章、第十二章