《易學 設計模式》 - 書摘精要

(前言)

設計模式和具體的語言沒有關係，學習設計模式最重要的目的就是要建立面向對象的思想，儘可能地面向接口編程、低耦合、高內聚，使設計的程序可複用；

在掌握面向對象的思想方式後，再回過頭來看設計模式，就會有更深刻的理解；

學習設計模式，一定要勤學多練；

(P4)

對象的創建會消耗掉系統的很多資源，所以單獨對對象的創建進行研究，從而能夠高效地創建對象就是創建型模式要探討的問題；

在解決了對象的創建問題之後，對象的組成以及對象之間的依賴關係就成了開發人員關注的焦點，因爲如何設計對象的結構、繼承和依賴關係會影響到後續程序的維護性、代碼的健壯性、耦合性等。

對象結構的設計很容易體現出設計人員水平的高低；

在對象的結構和對象的創建問題都解決了之後，就剩下對象的行爲問題了，如果對象的行爲設計的好，那麼對象的行爲就會更清晰，它們之間的協作效率就會提高；

(P5)

設計模式並不只是一種方法和技術，它更是一種思想、一個方法論。

它和具體的語言沒有關係，學習設計模式最主要的目的就是要建立面向對象的思想，儘可能地面向接口編程、低耦合、高內聚，使你設計的程序儘可能地複用；

(P23)

簡單工廠模式又叫靜態工廠方法模式，是所有工廠模式中最簡單的一個；

在程序設計中，離不開對象的創建，對象創建效率的高低對系統資源的佔用影響較大，因此需要對此進行詳細研究，最好的辦法就是將對象的創建和使用分開；

簡單工廠模式只適用於要創建的具體對象比較少或簡單的情況，而創建比較複雜的對象時，簡單工廠模式不是一個很好的選擇；

(P31)

工廠方法模式相對於簡單工廠模式來說，就是把一個單一的工廠類，分成了多個具體的小工廠，並抽象出了一個工廠類，這個工廠類只負責定義創建的方式，創建的具體內容由繼承它的小工廠類實現；

(P35)

【工廠方法模式】

[定義] 工廠方法模式中抽象工廠類負責定義創建對象的接口，具體對象的創建工作由實現抽象工廠的具體工廠類來完成；

[原理] 工廠方法模式主要由4部分組成：抽象工廠類、實現抽象工廠類的具體工廠類、抽象類和實現抽象類的具體類；

[使用時機] 當在代碼中使用new來創建對象時，就可以考慮使用工廠方法模式。一般來說，工廠方法模式會應用在比較複雜的對象創建上；

[優點]

在工廠方法模式中，客戶端不再負責對象的創建，而是把這個責任交給了具體的工廠類，客戶端只負責對象的調用，從而明確了各個類的職責；

如果有新的產品加進來，只需要新增加一個具體的創建產品工廠類和具體的產品類就可以了，不會影響到原來已有的其他代碼，代碼量也不會變大，後期維護更加容易，增強了系統的可擴展性；

[缺點] 使用該模式需要額外地編寫代碼，增加了工作量；

(P39)

每一種設計模式都是爲了解決一類問題而產生的，如果說工廠方法模式是針對一個產品結構而言的話，那麼抽象工廠模式就是針對於多個產品結構而言的，它主要用於幫助客戶一次創建多個不同產品對象；

(P40)

工廠方法模式是針對於一個產品系列的，而抽象工廠模式是針對於多個產品系列的，即工廠方法模式是一個產品系列一個工廠類，而抽象工廠模式是多個產品系列一個工廠類；

(P45)

【抽象工廠模式】

[定義] 如果客戶端需要創建一些產品結構，而這些產品結構又分別屬於不同的產品類別，則可以使用抽象工廠模式，抽象工廠模式中抽象工廠類負責定義創建對象的接口，這一系列對象的創建工作由實現抽象工廠的具體工廠類來具體完成；

[原理] 抽象工廠模式主要由4部分組成：抽象工廠類、實現抽象工廠類的具體工廠類、抽象類和實現抽象類的具體類；

[使用時機] 當系統需要創建一系列相互關聯的對象時，就需要使用抽象工廠模式；

[優點]

在抽象工廠模式中，客戶端不再負責對象的創建，而是把這個責任交給了具體的工廠類，客戶端只負責對對象的調用，從而明確了各個類的職責；

當一系列相互關聯的產品被設計到一個工廠類裏後，客戶端的調用將會變得非常簡單，而且，如果要更換這一系列的產品，只需要更換一個工廠類即可；

[缺點] 如果有新的產品加進來，則需要修改抽象工廠類的設計，並同時修改實現這個抽象工廠類的具體工廠類，需要額外編寫代碼，增加了工作量；

(P52)

在簡單工廠模式中，一個工廠類負責所有產品對象的創建，這個工廠類的職責大大增加。由於簡單工廠模式使用靜態方法來創建對象，這就導致靜態方法無法被繼承；

在工廠方法模式中，一個具體的工廠類負責創建一個單獨的產品，如果有兩個不同的產品要創建，就需要兩個不同的工廠類，即使這兩個產品有某些必要的聯繫，也還是需要兩個不同的工廠類；

在抽象工廠模式中，一個具體的工廠類負責創建一系列相互關聯的產品，當一系列相互關聯的產品被設計到一個工廠類裏後，客戶端的調用將會變得非常簡單；如果要更換這一系列的產品，則只需要更換一個工廠類即可；

(P57)

【創建者模式】

[定義] 創建者模式就是將一個複雜對象的構建與它的表示相分離，使得同樣的構建過程可以創建不同的表示，而且客戶端不知道對象的構建細節；

[原理] 創建者模式主要由5個部分組成：組裝類、抽象創建者類、實現抽象創建者類的具體創建者類、抽象產品類和實現抽象產品類的具體產品類；

[使用時機] 當系統需要創建一個複雜的對象，而且這個複雜的對象組裝起來比較麻煩時，就可以使用創建者模式；

[優點] 在創建者模式中，客戶端不再負責對象的創建和組裝，而是把這個創建的責任交給具體的創建者類，把組裝的責任交給組裝類，客戶端只負責對象的調用，從而明確了各個類的職責；

[缺點] 雖然利用創建者模式可以創建出不同類型的產品，但如果產品之間的差異非常大，則需要編寫多個創建者類才能實現，這時如果結合工廠模式更好；

(P64)

【原型模式】

[定義] 原型模式就是通過一個原型對象來表明要創建的對象類型，然後用複製這個原型對象的方法來創建更多同類型對象；

[原理] 原型模式主要由2部分組成：抽象原型和具體原型類；

[使用時機] 當系統需要創建的對象是動態加載的，而且產品具有一定層次時，需要使用原型模式；

[優點] 在原型模式中，可以動態地添加產品類，而且對整體結構沒有影響；

[缺點] 由於原型模式需要給每個類都配備一個克隆的方法，這就需要在設計類時通盤考慮，因爲在已有類的基礎上來添加clone操作是比較困難的；而且原型模式在實現深層次的複製時，需要編寫一定量的代碼；

(P73)

【單例模式】

[定義] 單例模式就是確保一個類只有一個實例，並且該實例必須自動創建，並向整個系統提供該實例；

[原理] 單例模式可以分爲餓漢式單例模式和懶漢式單例模式兩種：餓漢式單例模式在類初始化時就已經創建了自身的對象，而懶漢式單例模式則是在需要使用的時候才創建自身的對象；

[使用時機] 當系統要求一個類只有一個實例時，就需要使用單例模式；

[優點] 在單例模式中，客戶調用類的實例時，只能調用一個公共的接口，這就爲整個開發團隊提供了一個共享的概念；

[缺點] 實現單例模式的類在實例化後，不能被別的類繼承；在分佈式系統中，當系統中的單例類被複制運行在多個虛擬機下時，在每一個虛擬機下都會創建一個實例對象，此時如果想知道具體哪個虛擬機下運行着哪個單例對象時很困難的，而且單例類很難實現序列化；

(P79)

在所有的設計模式中，最簡單的就數外觀模式了。外觀模式又叫門面模式，顧名思義，就是對一個系統進行包裝，該系統對外的接口統一由外觀類進行提供；

【外觀模式】

[定義] 外觀模式就是爲子系統對外提供的一組接口提供一個統一的界面，使得其他系統對該系統的訪問都通過這個統一的界面來完成；

[原理] 外觀模式主要由3部分組成：抽象外觀類、實現抽象外觀類的具體外觀類和其他子系統；

[使用時機] 當一個複雜的系統需要對外提供接口時，就需要將對外提供的接口統一封裝在一個外觀類裏，供外系統使用；

[優點] 外觀模式通過提供一個統一的對外接口，避免了外部系統和子系統之間的直接聯繫，從而降低了系統間的依賴和複雜度；

[缺點] 限制了外部系統對子系統調用的靈活性，只能按照外觀類中提供的方式對子系統進行調用；

(P107)

【適配器模式】

[定義] 適配器模式就是將一個系統的接口轉換成另外一種形式，從而使原來不能直接調用的接口變得可以調用；

[原理] 適配器模式主要由3部分組成：目標類、源類和適配器類；

適配器類分爲對象適配器和類適配器：對象適配器即實現目標類的接口，依賴適配者類；類適配器即直接繼承適配者類，並實現目標類的接口；

[使用時機] 當系統需要使用一個外部接口，而這個外部接口不符合系統需要的時候，就需要使用適配器模式；

[優點] 使用適配器模式，可以將一個系統的接口和本來不相容的另一個系統的類聯繫起來，從而使得這兩個類能夠在一起工作，強調了對接口的轉換；

[缺點] 對於類適配器來說，不能適配一個類以及它的子類；對於對象適配器來說，重新定義被適配的類的行爲比較困難；

(P122)

【代理模式】

[定義] 代理模式就是給一個對象提供一個代理對象，由這個代理對象控制對原對象的引用，使代理類在客戶端和原對象之間起到一箇中介的作用；

[原理] 代理模式主要由3部分組成：抽象目標類、具體目標類和代理類；

[使用時機] 當系統需要對某個對象進行額外的控制時，就需要使用代理模式；

[優點] 使用代理模式，能夠在不改變原來代碼功能的基礎上對某一對象進行額外的控制，從而更好地體現了面向對象中單一職責的思想；

[缺點] 對於靜態代理來說，一個接口只服務於一種類型，如果要代理的方法很多，則要爲每個方法定義一個接口；

(P153)

【裝飾模式】

[定義] 裝飾模式就是使用被裝飾類的一個子類的實例，在客戶端將這個子類的實例委託給裝飾類。裝飾模式是繼承關係的一個替代方案；

[原理] 裝飾模式主要由4部分組成：抽象的被裝飾類、具體的被裝飾類、抽象的裝飾類和具體的裝飾類；

[使用時機] 當系統需要擴展一個類的功能，或者客戶端需要動態的給一個對象添加功能，並且此時如果使用繼承會很複雜時，就需要使用裝飾模式；

[優點] 使用裝飾模式，能夠提供比使用繼承關係更靈活的擴展對象的功能，它可以動態地增加對象的功能，並且可以隨意地組合這些功能；

[缺點] 正因爲可以隨意地組合這些功能，有時候就可能會出現一些不合理的邏輯。使用裝飾模式進行系統設計往往會產生許多看上去類似的小對象，這些對象的類或是它們的屬性值是一樣的，僅僅在它們相互連接的方式上有所不同；

(P171)

橋模式可能是所有設計模式中最難理解的一個模式了；

橋模式中的抽象指的是抽象類及派生類，實現指的是這些抽象類及派生類實現自己的方式；

【橋模式】

[定義] 橋模式就是將抽象與其實現解耦，使它們可以分別獨立地變化。橋模式也是繼承關係的一個替代方案；

[原理] 橋模式主要由4部分組成：抽象類、抽象類的繼承類、實現類和實現類的繼承類；

[使用時機] 當系統需要在它的抽象和實現之間增加更多的靈活性，或者一個對象有多於一個的抽象和實現時，就需要使用橋模式；

[優點] 使用橋模式，能夠提供比使用繼承關係更靈活的功能。它可以使抽象和實現分離開，降低了耦合關係。當有新的抽象或實現方式時，只需要繼承一個抽象和繼承一個實現即可；

[缺點] 如果要重新抽象出另外一個類型，則需要修改抽象；

(P196)

適配器、代理、裝飾和橋模式都是爲了解決對象之間的依賴關係，降低對象間的耦合度，給設計增加更多的靈活性；

(P201)

【組合模式】

[定義] 組合模式就是把部分和整體的關係用樹形結構來表示，從而使客戶端能夠把一個一個的部分對象和由它們組合起來的整體對象採用同樣的方式來看待。它也是繼承的一個替代方案；

[原理] 組合模式主要由3部分組成：抽象類、葉子類和父類；

[使用時機] 當系統要描述的對象是樹形結構，並且要在客戶端忽略掉子對象和父對象的區別時，就需要使用組合模式；

[優點] 使用組合模式，能夠提供比使用繼承關係更靈活的功能，並且可以靈活地組合子對象和父對象之間的關係，從而使客戶端的調用簡單，客戶端可以一致地使用組合結構或其中單個對象，用戶就不必關心自己處理的是單個對象還是整個組合結構，這簡化了客戶端代碼；

[缺點] 雖然組合模式使得向集合添加新類型的組件變得容易，只要這些組件提供一個相似的編程接口即可，但這也是它的缺點，因爲這種做法很難限制某個類；

(P220)

【享元模式】

[定義] 享元模式就是把部分和整體的關係用樹形結構來表示，從而使客戶端能夠把一個一個的部分對象和由它們組合起來的整體對象採用同樣的方式來看待。它也是繼承的一個替代方案；

[原理] 享元模式主要由3部分組成：享元類、具體的享元類和享元工廠類；

[使用時機] 當系統需要使用大量重複的對象，而且這些對象要消耗很大的內存時，就需要使用享元模式；

[優點] 使用享元模式，可以爲系統節省大量的空間；

[缺點] 但是在享元工廠裏可以看到，需要維護所有的享元對象，如果要維護的享元很多，在查找的時候要消耗大量的時間。因此，享元模式是典型的以時間換空間；

(P227)

結構型模式主要解決了對象的組成以及對象之間的依賴關係；


(P234)

【模板方法模式】

[定義] 模板方法模式就是定義一個算法執行的骨架，而將具體的算法延遲到子類中來實現；

[原理] 模板方法模式主要由2部分組成：抽象的骨架類和具體實現類；

[使用時機] 當系統中算法的骨架是固定的，而算法的實現可能有很多種的時候，就需要使用模板方法模式；

[優點] 使用模板方法模式，在定義算法的骨架的同時，可以很靈活地實現具體的算法，滿足用戶靈活多變的需求；

[缺點] 雖然使用模板方法模式可以很自由地實現具體的算法，但如果算法的骨架有改變的話，則需要修改抽象類；

(P270)

【觀察者模式】

[定義] 觀察者模式就是定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新；

[原理] 觀察者模式主要由4部分組成：抽象目標類、具體目標類、抽象觀察者類和具體觀察者類；

[使用時機] 當對一個對象的改變需要同時改變其他對象，而不知道具體有多少對象有所改變，或者說當一個對象必須通知其他對象，而它又不能假定其他對象是誰的時候，就需要使用觀察者模式；

[優點] 觀察者模式在被觀察者和觀察者之間建立一個抽象的耦合，每一個具體觀察者都符合一個抽象觀察者的接口，被觀察者並不知道任何一個具體觀察者，它只知道它們都有一個共同的接口，從而使得被觀察者和觀察者耦合度降低，而且觀察者模式支持廣播通信。被觀察者會向所有的註冊過的觀察者發出通知；

[缺點] 如果一個被觀察者對象有很多觀察者，通知所有的觀察者會耗費很多時間；

(P286)

【狀態模式】

[定義] 狀態模式就是根據對象的狀態不同，將有不同的行爲；

[原理] 狀態模式主要由3部分組成：抽象狀態類、具體狀態類和上下文類；

[使用時機] 當一個對象的行爲取決於它的狀態，並且它必須在運行時刻根據狀態改變它的行爲，或者一個操作中含有龐大的多分支的條件語句，且這些分支依賴於該對象的狀態時，就需要使用狀態模式；

[優點] 狀態模式使代碼中複雜而冗長的邏輯判斷語句問題得到了解決，而且具體狀態角色將具體狀態和它對應的行爲封裝了起來，這使得增加一種新的狀態變得十分簡單；

[缺點] 使用狀態模式時，每個狀態對應一個具體的狀態類。使結構分散，邏輯不太清晰，閱讀代碼時比較困難；

(P299)

【策略模式】

[定義] 策略模式就是定義了一系列的算法，並將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法獨立於使用它的客戶而獨立變化；

[原理] 策略模式主要由3部分組成：抽象策略類、具體策略類和上下文場景類；

[使用時機] 當系統需要能夠在幾種算法中快速地切換，或系統中有一些類，它們僅行爲不同時，或系統中存在多重條件選擇語句時，就可以考慮採用策略模式；

[優點] 使用策略模式，可以替換繼承關係的辦法，也可以避免使用多重條件轉移語句；

[缺點] 使用策略模式時客戶端必須知道所有的策略類，並自行決定使用哪一個策略類，如果算法比較多，則會造成很多的策略類；

(P305)

【職責鏈模式】

[定義] 職責鏈模式就是使多個對象都有機會處理請求，從而避免請求的發送者和接受者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止；

[原理] 職責鏈模式主要由2部分組成：抽象處理類、具體處理類和上下文場景類；

[使用時機] 當有多個對象處理請求，而且需要動態指定處理者的時候，就可以考慮使用職責鏈模式；

[優點] 使用職責鏈模式可以降低類之間的耦合度。使得處理類僅需要保持一個指向其後繼者的引用，也使得一個對象無需知道是其他哪一個對象處理其請求。對象僅需知道該請求會被正確地處理，接收者和發送者都沒有對方的明確的信息，這種處理方法增強了給對象指派職責的靈活性；

[缺點] 因爲對象不知道是其他哪一個對象處理其請求的，所以職責鏈模式不保證對象被接收，從而使得該請求可能一直到鏈接的末端都得不到處理；

(P316)

【命令模式】

[定義] 命令模式就是把一個請求或者操作封裝到一個對象中。命令模式允許系統使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日誌，可以提供命令的撤銷和恢復功能；

[原理] 命令模式主要由4部分組成：抽象命令類、具體命令類、調用者和接收者；

[使用時機] 當需要先將一個函數登記上，然後在以後調用此函數時，就需要使用命令模式，其實這就是回調函數；

[優點] 命令模式把請求一個操作的對象與知道怎麼執行一個操作的對象分割開，從而使新的命令可以很容易地被加入到系統裏，可以很方便地設計命令隊列，也可以很容易地實現對請求的撤銷和重做，由於加進新的具體命令類不影響其他的類，因此增加新的具體命令很容易；

[缺點] 使用命令模式會導致某些系統有過多的具體命令類，這使得太多的命令類難於管理；

(P342)

【訪問者模式】

[定義] 訪問者模式表示一個作用於某對象結構中的各元素的操作。它使開發者可以在不改變各元素的類的前提下定義作用於這些元素的新操作；

[原理] 訪問者模式主要由5部分組成：抽象訪問者類、具體訪問者類、抽象元素類、具體元素類和對象結果類；

[使用時機] 當一個對象結構包含很多類對象，它們有不同的接口，而系統要求這些對象實施一些依賴於其具體類的操作時，就可以考慮使用訪問者模式；

[優點]  使用了訪問者模式以後，對於原來的類層次增加新的操作，僅僅需要實現一個具體訪問者角色就可以了，而不必修改整個類層次，而且每個具體的訪問者角色都對應於一個相關操作，因此如果一個操作的需求有變，就不用改動整個類層次，只需修改一個具體訪問者角色即可；

[缺點] 如果系統中的類層次發生了變化，就必須修改訪問者角色和每一個具體訪問者角色，因此訪問者模式不適合具體元素角色經常發生變化的情況；

(P348)

【調停者模式】

[定義] 調停者模式就是用一箇中介者對象來封裝一系列的對象交互。中介者使各對象不需要顯示地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互；

[原理] 調停者模式主要由4部分組成：抽象調停者類、具體調停者類、抽象同事類和具體同事類；

[使用時機] 當一組對象以定義良好但是複雜的方式進行通信，而且這些對象產生的相互依賴關係結構混亂且難以理解，或一個對象引用其他很多對象並且直接與這些對象通信，導致難以複用該對象時，就可以考慮使用調停者模式；

[優點] 當使用調停者模式時，它將各個通信的對象進行解耦，使得原本分佈於多個對象間的行爲集中在一起，改變這些行爲只需生成的協調類即可，這樣的關係使得程序更易於理解、維護和擴展；

[缺點] 調停者模式使控制集中化，因爲所有的交互行爲都集中在調停者類中，使得這個類變得龐大而複雜，從而難以維護；

(P355)

【備忘錄模式】

[定義] 備忘錄模式就是一個保存另外一個對象內部狀態複製的對象，這樣以後就可以將該對象恢復到原先保存的狀態；

[原理] 備忘錄模式主要由2部分組成：源發器類和備忘錄類；

[使用時機] 當系統必須要保存一個對象在某一個時刻的狀態，以方便需要時能恢復到先前的狀態時，就需要考慮使用備忘錄模式；

[優點] 使用備忘錄模式，可以避免暴露一些只應由源發器管理卻又必須存儲在源發器之外的信息，而且能夠在對象需要時恢復到先前的狀態；

[缺點] 使用備忘錄可能代價很高。如果源發器在生成備忘錄時必須複製並存儲大量的信息，或者客戶非常頻繁地創建備忘錄和恢復源發器狀態，可能會導致非常大的開銷；

(P358)

【迭代器模式】

[定義] 迭代器模式提供一種順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示的方法；

[原理] 迭代器模式主要由4部分組成：迭代器角色、具體迭代器角色、容器角色和具體容器角色；

[使用時機] 當訪問一個聚合對象的內容而無需暴露它的內部表示，或者需要支持對聚合對象的多種遍歷，或者需要爲遍歷不同的聚合結構提供一個統一的接口時，就可以考慮使用迭代器模式；

[優點] 迭代器模式分離了集合對象的遍歷行爲，抽象出一個迭代器類來負責，這樣既可以做到不暴露集合的內部結構，又可讓外部代碼透明地訪問集合內部的數據；

[缺點] 迭代器模式是爲容器而存在的，因此它僅適用於對容器的訪問；

(P385)

【解釋器模式】

[定義] 解釋器模式給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子；

[原理] 解釋器模式主要由4部分組成：抽象表達式角色、終結符表達式角色、非終結符表達式和上下文；

[使用時機] 當有一個語言需要解釋執行，並且可將該語言中的句子表示爲一個抽象語法樹時，就可以考慮使用解釋器模式；

[優點] 解釋器模式提供了一個簡單的方式來執行語法，而且容易修改或者擴展語法，但解釋器模式比較適用於文法簡單並且對處理的效率要求較低的情況；

[缺點] 對於複雜的文法，解釋器模式將不是一個很好的選擇，因爲複雜文法的類層次變得龐大而無法管理，此時語法分析程序生成器這樣的工具是更好的選擇，它們無需構建抽象語法樹即可解釋表達式，這樣可以節省空間而且還可能節省時間；

(P387)

【單一職責原則 (SRP)】

單一職責原則的核心思想就是：系統中的每一個對象都應該只有一個單獨的職責，而所有對象所關注的就是自身職責的完成。它的英文縮寫是 SRP，英文全稱是 Single Responsibility Principle。

其實單一職責原則的意思就是：開發人員經常說的“高內聚、低耦合”。也就是說，每個類應該只有一個職責，對外只能提供一種功能，而引起類變化的原因應該只有一個。在設計模式中，所有的設計模式都遵循這一原則；

【開閉原則 (OCP)】

開閉原則的核心思想就是：一個對象對擴展開放，對修改關閉。它的英文縮寫是 OCP，英文全稱是 Open for Extension, Closed for Modification。

其實開閉原則的意思就是：對類的改動是通過增加代碼進行的，而不是改動現有的代碼。也就是說，軟件開發人員一旦寫出了可以運行的代碼，就不應該去改變它，而是要保證它能一直運行下去，如何才能做到這一點呢？這就需要藉助於抽象和多態，即把可能變化的內容抽象出來，從而使抽象的部分是相對穩定的，而具體的實現層則是可以改變和擴展的；

【里氏替換原則 (LSP)】

里氏替換原則的核心思想就是：在任何父類出現的地方都可以用它的子類來替代。它的英文縮寫是 LSP，英文全稱是 Liskov Substitution Principle。

其實里氏替換原則的意思就是：同一個繼承體系中的對象應該有共同的行爲特徵。里氏替換原則關注的是怎樣良好地使用繼承，也就是說不要濫用繼承，它是繼承複用的基石；

【依賴注入原則 (DIP)】

依賴注入原則的核心思想就是：要依賴於抽象，不要依賴於具體的實現。它的英文縮寫是 DIP，英文全稱是 Dependence Inversion Principle。

其實依賴注入原則的意思就是：在應用程序中，所有的類如果使用或依賴於其他的類，則都應該依賴於這些其他類的抽象類，而不是這些其他類的具體實現類。抽象層次應該不依賴於具體的實現細節，這樣才能保證系統的可複用性和可維護性。爲了實現這一原則，就要求開發人員在編程時要針對接口編程，而不針對實現編程；

【接口分離原則 (ISP)】

接口分離原則的核心思想就是：不應該強迫客戶程序依賴它們不需要使用的方法。它的英文縮寫是 ISP，英文全稱是 Interface Segregation Principle。

其實接口分離原則的意思就是：一個接口不需要提供太多的行爲，一個接口應該只提供一種對外的功能，不應該把所有的操作都封裝到一個接口當中；

【迪米特原則 (LOD)】

迪米特原則的核心思想就是：一個對象應當對其他對象儘可能少的瞭解。它的英文縮寫是 LOD，英文全稱是 Law of Demeter。

其實迪米特原則的意思就是：降低各個對象之間的耦合，提高系統的可維護性。在模塊之間，應該只通過接口來通信，而不理會模塊的內部工作原理，它可以使各個模塊耦合程度降到最低，促進軟件的複用；

【優先使用組合而不是繼承原則 (CARP)】

優先使用組合而不是繼承原則的核心思想就是：優先使用組合，而不是繼承。它的英文縮寫是 CARP，英文全稱是 Composite / Aggregate Reuse Principle。

其實優先使用組合而不是繼承原則的意思就是：在複用對象的時候，要優先考慮使用組合，而不是繼承，這是因爲在使用繼承時，父類的任何改變都可能影響子類的行爲，而在使用組合時，是通過獲得對其他對象的引用而在運行時刻動態定義的，有助於保持每個類的單一職責原則；