設計模式六大原則
開閉原則
開閉原則，是說對于軟體實體(類、子產品、函數等等)應該可以拓展，但是不可修改
這句話有兩個意思，對于拓展是開放的，對于更改是封閉的。在設計一個軟體之前，就需要考慮到怎樣的設計才能面對需求的改變卻可以保持相對穩定，進而使得系統可以在第一個版本之後不斷推出新的版本？設計軟體要容易維護又不容易出問題的最好方法就是使其變得易于拓展，少修改
學習完了開閉原則之後，我才更加注意到為什麼設計模式這個知識點需要使用到這種原則，開閉原則的要求，更加需要開發人員在剛開始對軟體進行開發的時候，從剛開始編寫代碼就要對子產品進行仔細和完善地分析，從剛開始就需要為以後可能會到來的變化做好準備，因為隻有這樣，才能解決之後的變化不會影響到已經編寫過的代碼，真正實作不修改已經完成的子產品，通過增加新的抽象或者别的方式來實作開閉原則實作需求變更之後的需求
無論子產品是多麼的‘封閉’，都會出現一些無法對之封閉的變化，既然不可能完全封閉，設計人員必須對于他設計的子產品應該對哪種變化封閉做出選擇，必須先要猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化
面對需求，開閉原則要求我們做到，對程式的改動是通過增加新代碼進行的，而不是更改現有的代碼
開放-封閉原則是面向對象設計的核心所在，遵循這個原則則可以帶來面向對象技術所聲稱的巨大好處，也就是可維護、可拓展、可複用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的哪些部分做出抽象，然而，對于應用程式中每個部分都刻意進行抽象并不是一個好主意，拒絕不成熟的抽象在開發過程中以及設計模式中尤為重要
單一職責原則
單一職責原則是說，就一個類而言，應該僅有一個引起它變化的原因
大多數時候，一件産品簡單一點，職責單一一點，或許是更好的選擇
為什麼需要有單一職責原則
- 如果一個類承擔的職責過多，就等于把這些職責耦合在了一起，一個職責改變的時候可能會影響或者削弱這個類完成其餘職責的能力，這種耦合會導緻存在脆弱的設計，當變化發生的時候，設計會遭受到意想不到的破壞
- 軟體設計真正要做的許多内容，就是發現職責并把那些職責互相分離，其實要去判斷是否應該分離出來，也不難，那就是如果你能夠想到多于一個的職責，就應該考慮類的職責分離，而程式設計的時候，我們卻是要在類的職責分離上多思考，做到單一職責，這樣代碼才是真正的易維護、易拓展、易複用、靈活性強
舉一個例子：
初始設計方案UML圖
CustomerDataChart類中的方法說明如下：getConnection()方法用于連接配接資料庫，findCustomers()用于查詢所有的客戶資訊，createChart()用于建立圖表，displayChart()用于顯示圖表。
圖中，CustomerDataChart類承擔了太多的職責，既包含與資料庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連接配接資料庫或者使用findCustomers()方法查詢客戶資訊，則難以實作代碼的重用。無論是修改資料庫連接配接方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責原則。是以需要對該類進行拆分，使其滿足單一職責原則，類CustomerDataChart可拆分為如下三個類：
- DBUtil：負責連接配接資料庫，包含資料庫連接配接方法getConnection()；
- CustomerDAO：負責操作資料庫中的Customer表，包含對Customer表的增删改查等方法，如findCustomers()；
- CustomerDataChart：負責圖表的生成和顯示，包含方法createChart()和displayChart()。
重構後結構
裡氏代換原則
裡氏代換原則說白了就是指一個軟體實體如果使用的是一個父類的話，那麼一定适用于子類，而且它察覺不出父類對象和子類對象的差別，也就是說，在軟體裡面，把父類都替換為它的子類，程式的行為沒有發生變化，子類型必須能夠替換掉他們的父類型
隻有當子類可以替換掉父類，軟體機關的功能不受影響的時候，父類才能真正被複用，而子類也能夠在父類基礎上增加新的行為。也正是因為有了裡氏代換原則，才能使得開閉原則成為可能，這樣說是可以的，正是由于子類型的可替換性才是的使用父類類型的子產品在無需修改的情況下可以進行拓展
裡氏代換原則告訴我們，在軟體中将一個基類對象替換成它的子類對象，程式将不會産生任何錯誤和異常，反過來則不成立，如果一個軟體實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。
在使用裡氏代換原則時需要注意如下幾個問題：
- 子類的所有方法必須在父類中聲明，或子類必須實作父類中聲明的所有方法。根據裡氏代換原則，為了保證系統的擴充性，在程式中通常使用父類來進行定義，如果一個方法隻存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
- 我們在運用裡氏代換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或實作父接口，并實作在父類中聲明的方法，運作時，子類執行個體替換父類執行個體，我們可以很友善地擴充系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實作。裡氏代換原則是開閉原則的具體實作手段之一。
- Java語言中，在編譯階段，Java編譯器會檢查一個程式是否符合裡氏代換原則，這是一個與實作無關的、純文法意義上的檢查，但Java編譯器的檢查是有局限的。(多态)
在一個系統中，客戶(Customer)可以分為VIP客戶(VIPCustomer)和普通客戶(CommonCustomer)兩類，系統需要提供一個發送Email的功能，原始設計方案如圖所示：
原始結構圖
在對系統進行進一步分析後發現，無論是普通客戶還是VIP客戶，發送郵件的過程都是相同的，也就是說兩個send()方法中的代碼重複，而且在本系統中還将增加新類型的客戶。為了讓系統具有更好的擴充性，同時減少代碼重複，使用裡氏代換原則對其進行重構
在本執行個體中，可以考慮增加一個新的抽象客戶類Customer，而将CommonCustomer和VIPCustomer類作為其子類，郵件發送類EmailSender類針對抽象客戶類Customer程式設計，根據裡氏代換原則，能夠接受基類對象的地方必然能夠接受子類對象，是以将EmailSender中的send()方法的參數類型改為Customer，如果需要增加新類型的客戶，隻需将其作為Customer類的子類即可。重構後的結構如圖所示：
重構後的結構圖
裡氏代換原則是實作開閉原則的重要方式之一。在本執行個體中，在傳遞參數時使用基類對象，除此以外，在定義成員變量、定義局部變量、确定方法傳回類型時都可使用裡氏代換原則。針對基類程式設計，在程式運作時再确定具體子類。
依賴倒置原則
依賴倒置原則是說，高層子產品不應該依賴低層子產品，兩個都應該依賴抽象。抽象不應該依賴細節，細節應該依賴抽象，換言之，要針對接口程式設計，而不是針對實作程式設計
依賴倒轉原則要求我們在程式代碼中傳遞參數時或在關聯關系中，盡量引用層次高的抽象層類，即使用接口和抽象類進行變量類型聲明、參數類型聲明、方法傳回類型聲明，以及資料類型的轉換等，而不要用具體類來做這些事情。為了確定該原則的應用，一個具體類應當隻實作接口或抽象類中聲明過的方法，而不要給出多餘的方法，否則将無法調用到在子類中增加的新方法。
在實作依賴倒轉原則時，我們需要針對抽象層程式設計，而将具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發生依賴關系時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分别是：構造注入，設值注入（Setter注入）和接口注入。構造注入是指通過構造函數來傳入具體類的對象，設值注入是指通過Setter方法來傳入具體類的對象，而接口注入是指通過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型，在運作時再傳入具體類型的對象，由子類對象來覆寫父類對象。
舉一個《大話設計模式》中的例子可以把PC電腦了解為一個大型的軟體系統，PC内部的部件，如CPU、記憶體、磁盤等不管哪一個出現了問題，都可以在不影響别的前提下進行替換或者進行修改，這是基于PC的易插拔，面向對象中将這種關系稱為，強内聚，低耦合
再比如CPU，因為CPU對外都是針腳式或者觸點式等等的标準接口，這就是接口最大的好處，CPU隻需要把接口定義好，而内部的具體實作，哪怕再複雜也不會暴露給外部，而主機闆隻需要保留對CPU标準接口的插槽即可，如果這個時候有一個電腦壞了的場景，經過分析是記憶體不夠使用導緻的，那麼這個時候根據上述介紹過的開閉原則，隻要主機闆上還有記憶體的插槽，那麼就可以通過增加記憶體來維修此次故障，而不用對之前的記憶體條進行任何的修改，硬碟不夠的話，可以考慮使用移動硬碟等等，這種思想就是上述介紹過的開閉原則，那麼為什麼記憶體出現了問題就去更換或者增加記憶體，而不是去找CPU或者别的部件的問題呢，這就是因為單一職責原則，這個時候記憶體負責的單一職責出現了問題就及時區尋找記憶體的問題，而不用去逐個排查别的部件是否出現問題。依賴倒置原則說白了就是面向接口程式設計，不是對實作進行程式設計，如果僅僅是面向接口程式設計，那麼當計算機PC發生問題的時候，就可以通過增加或者更新新的部件進行維護，而如果是面向實作，記憶體就要對應到具體的某一個品牌的主機闆，那麼可能記憶體出現了問題，還需要更換主機闆等一系列部件，導緻無所謂的開銷
某公司設計一個系統，該系統經常需要将存儲在TXT或Excel檔案中的客戶資訊轉存到資料庫中，是以需要進行資料格式轉換。在客戶資料操作類中将調用資料格式轉換類的方法實作格式轉換和資料庫插入操作，初始設計方案結構：
初始設計方案結構圖
由于每次轉換資料時資料來源不一定相同，是以需要更換資料轉換類，如有時候需要将TXTDataConvertor改為ExcelDataConvertor，此時，需要修改CustomerDAO的源代碼，而且在引入并使用新的資料轉換類時也不得不修改CustomerDAO的源代碼，系統擴充性較差，違反了開閉原則，現需要對該方案進行重構。
由于CustomerDAO針對具體資料轉換類程式設計，是以在增加新的資料轉換類或者更換資料轉換類時都不得不修改CustomerDAO的源代碼。我們可以通過引入抽象資料轉換類解決該問題，在引入抽象資料轉換類DataConvertor之後，CustomerDAO針對抽象類DataConvertor程式設計，而将具體資料轉換類名存儲在配置檔案中，符合依賴倒轉原則。根據裡氏代換原則，程式運作時，具體資料轉換類對象将替換DataConvertor類型的對象，程式不會出現任何問題。更換具體資料轉換類時無須修改源代碼，隻需要修改配置檔案；如果需要增加新的具體資料轉換類，隻要将新增資料轉換類作為DataConvertor的子類并修改配置檔案即可，原有代碼無須做任何修改，滿足開閉原則。重構後的結構：
在上述重構過程中，我們使用了開閉原則、裡氏代換原則和依賴倒轉原則，在大多數情況下，這三個設計原則會同時出現，開閉原則是目标，裡氏代換原則是基礎，依賴倒轉原則是手段，它們相輔相成，互相補充，目标一緻，隻是分析問題時所站角度不同而已。
依賴倒轉原則其實可以說是面向對象設計的标志，用哪種語言來編寫程式并不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節棉城，即程式中所有依賴關系都是終止與抽象類或者接口，那就是面向對象的設計，否則那就是過程化的設計了
接口隔離原則
接口隔離原則：使用多個專門的接口，而不使用單一的總接口，即用戶端不應該依賴那些它不需要的接口。
根據接口隔離原則，當一個接口太大時，我們需要将它分割成一些更細小的接口，使用該接口的用戶端僅需知道與之相關的方法即可。每一個接口應該承擔一種相對獨立的角色，不幹不該幹的事，該幹的事都要幹。這裡的“接口”往往有兩種不同的含義：一種是指一個類型所具有的方法特征的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴格的定義和結構，比如Java語言中的interface。對于這兩種不同的含義，ISP的表達方式以及含義都有所不同：
- 當把“接口”了解成一個類型所提供的所有方法特征的集合的時候，這就是一種邏輯上的概念，接口的劃分将直接帶來類型的劃分。可以把接口了解成角色，一個接口隻能代表一個角色，每個角色都有它特定的一個接口，此時，這個原則可以叫做“角色隔離原則”。
- 如果把“接口”了解成狹義的特定語言的接口，那麼接口隔離原則表達的意思是指接口僅僅提供用戶端需要的行為，用戶端不需要的行為則隐藏起來，應當為用戶端提供盡可能小的單獨的接口，而不要提供大的總接口。在面向對象程式設計語言中，實作一個接口就需要實作該接口中定義的所有方法，是以大的總接口使用起來不一定很友善，為了使接口的職責單一，需要将大接口中的方法根據其職責不同分别放在不同的小接口中，以確定每個接口使用起來都較為友善，并都承擔某一單一角色。接口應該盡量細化，同時接口中的方法應該盡量少，每個接口中隻包含一個用戶端（如子子產品或業務邏輯類）所需的方法即可，這種機制也稱為“定制服務”，即為不同的用戶端提供寬窄不同的接口。
某系統的客戶資料顯示子產品設計了如圖所示接口，其中方法dataRead()用于從檔案中讀取資料，方法transformToXML()用于将資料轉換成XML格式，方法createChart()用于建立圖表，方法displayChart()用于顯示圖表，方法createReport()用于建立文字報表，方法displayReport()用于顯示文字報表。
在圖中，由于在接口CustomerDataDisplay中定義了太多方法，即該接口承擔了太多職責，一方面導緻該接口的實作類很龐大，在不同的實作類中都不得不實作接口中定義的所有方法，靈活性較差，如果出現大量的空方法，将導緻系統中産生大量的無用代碼，影響代碼品質；另一方面由于用戶端針對大接口程式設計，将在一定程式上破壞程式的封裝性，用戶端看到了不應該看到的方法，沒有為用戶端定制接口。是以需要将該接口按照接口隔離原則和單一職責原則進行重構，将其中的一些方法封裝在不同的小接口中，確定每一個接口使用起來都較為友善，并都承擔某一單一角色，每個接口中隻包含一個用戶端（如子產品或類）所需的方法即可。
重構後的結構
在使用接口隔離原則時，我們需要注意控制接口的粒度，接口不能太小，如果太小會導緻系統中接口泛濫，不利于維護；接口也不能太大，太大的接口将違背接口隔離原則，靈活性較差，使用起來很不友善。一般而言，接口中僅包含為某一類使用者定制的方法即可，不應該強迫客戶依賴于那些它們不用的方法。
迪米特法則
迪米特法則是說，一個軟體實體應該盡可能少地與其他實體發生互相作用
如果一個系統符合迪米特法則，那麼當其中某一個子產品發生修改時，就會盡量少地影響其他子產品，擴充會相對容易，這是對軟體實體之間通信的限制，迪米特法則要求限制軟體實體之間通信的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持松散的耦合關系。
迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、隻與你的直接朋友通信等，在迪米特法則中，對于一個對象，其朋友包括以下幾類：
- 目前對象本身(this)；
- 以參數形式傳入到目前對象方法中的對象；
- 目前對象的成員對象；
- 如果目前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；
- 目前對象所建立的對象。
任何一個對象，如果滿足上面的條件之一，就是目前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象隻能與直接朋友發生互動，不要與“陌生人”發生直接互動，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。
迪米特法則要求我們在設計系統時，應該盡量減少對象之間的互動，如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的互相作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。
在将迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當盡量建立松耦合的類，類之間的耦合度越低，就越有利于複用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當盡量降低其成員變量和成員函數的通路權限；在類的設計上，隻要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
某系統包含很多業務操作視窗，在這些視窗中，某些界面控件之間存在複雜的互動關系，一個控件事件的觸發将導緻多個其他界面控件産生響應，例如，當一個按鈕(Button)被單擊時，對應的清單框(List)、組合框(ComboBox)、文本框(TextBox)、文本标簽(Label)等都将發生改變，在初始設計方案中，界面控件之間的互動關系可簡化為如圖所示結構：
初始結構
由于界面控件之間的互動關系複雜，導緻在該視窗中增加新的界面控件時需要修改與之互動的其他控件的源代碼，系統擴充性較差，也不便于增加和删除新控件。現使用迪米特對其進行重構。
在本執行個體中，可以通過引入一個專門用于控制界面控件互動的中間類(Mediator)來降低界面控件之間的耦合度。引入中間類之後，界面控件之間不再發生直接引用，而是将請求先轉發給中間類，再由中間類來完成對其他控件的調用。當需要增加或删除新的控件時，隻需修改中間類即可，無須修改新增控件或已有控件的源代碼，重構後結構如圖2所示：