1、設計原則概念

（1）單一職責原則：一個類只負責一個功能領域的相應職責或定義為只對外提供一種功能，即引起類變化的原因只有一個。

（2）開閉原則：軟體實體對擴充套件開放，對修改關閉。即軟體實體儘量在不修改原有程式碼的情況下進行擴充套件。

（3）里氏替換原則：任何使用基類的地方都可以使用其子類替換。是開閉原則的重要方式

（4）依賴倒置原則：抽象不依賴於細節，細節應該依賴於抽象。即要針對介面程式設計，而不是針對實現程式設計。

（5）介面隔離原則：使用多個專門的介面，而不使用大介面，即客戶端不應該依賴那些不需要的介面。每一個介面應該承擔一種相對獨立的角色，不幹不該乾的事，該乾的事都要幹。

（6）迪米特原則：

 2、具體解釋：

（1）單一職責原則

【作用】單一職責是實現高內聚、低耦合的指導方針，簡單但又最難運用，需設計者發現類的不同職責並對其進行分離。

【例項】下面通過一個簡單例項來進一步分析單一職責原則：

      在圖1中，CustomerDataChart類承擔了太多的職責，既包含與資料庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連線資料庫或者使用findCustomers()方法查詢客戶資訊，則難以實現程式碼的重用。無論是修改資料庫連線方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責原則。因此需要對該類進行拆分，使其滿足單一職責原則，類CustomerDataChart可拆分為如下三個類：

      (1) DBUtil：負責連線資料庫，包含資料庫連線方法getConnection()；

      (2) CustomerDAO：負責操作資料庫中的Customer表，包含對Customer表的增刪改查等方法，如findCustomers()；

      (3) CustomerDataChart：負責圖表的生成和顯示，包含方法createChart()和displayChart()。

      使用單一職責原則重構後的結構如圖2所示：

圖2  重構後的結構圖

（2）開閉原則

【作用】開閉原則是目標，抽象化是開閉原則的關鍵。

【例項】為了滿足開閉原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵。在Java、C#等程式語言中，可以為系統定義一個相對穩定的抽象層，而將不同的實現行為移至具體的實現層中完成。在很多面向物件程式語言中都提供了介面、抽象類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴充套件。如果需要修改系統的行為，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有程式碼的基礎上擴充套件系統的功能，達到開閉原則的要求。

       在本例項中，由於在ChartDisplay類的display()方法中針對每一個圖表類程式設計，因此增加新的圖表類不得不修改原始碼。可以通過抽象化的方式對系統進行重構，使之增加新的圖表類時無須修改原始碼，滿足開閉原則。具體做法如下：

      (1) 增加一個抽象圖表類AbstractChart，將各種具體圖表類作為其子類；

      (2)  ChartDisplay類針對抽象圖表類進行程式設計，由客戶端來決定使用哪種具體圖表。

      重構後結構如圖2所示：

圖2 重構後的結構圖

      在圖2中，我們引入了抽象圖表類AbstractChart，且ChartDisplay針對抽象圖表類進行程式設計，並通過setChart()方法由客戶端來設定例項化的具體圖表物件，在ChartDisplay的display()方法中呼叫chart物件的display()方法顯示圖表。如果需要增加一種新的圖表，如折線圖LineChart，只需要將LineChart也作為AbstractChart的子類，在客戶端向ChartDisplay中注入一個LineChart物件即可，無須修改現有類庫的原始碼。

       注意：因為xml和properties等格式的配置檔案是純文字檔案，可以直接通過VI編輯器或記事本進行編輯，且無須編譯，因此在軟體開發中，一般不把對配置檔案的修改認為是對系統原始碼的修改。如果一個系統在擴充套件時只涉及到修改配置檔案，而原有的Java程式碼或C#程式碼沒有做任何修改，該系統即可認為是一個符合開閉原則的系統。

（3）里氏替換原則

• 里氏代換原則告訴我們，在軟體中將一個基類物件替換成它的子類物件，程式將不會產生任何錯誤和異常，反過來則不成立，如果一個軟體實體使用的是一個子類物件的話，那麼它不一定能夠使用基類物件。例如：我喜歡動物，那我一定喜歡狗，因為狗是動物的子類；但是我喜歡狗，不能據此斷定我喜歡動物，因為我並不喜歡老鼠，雖然它也是動物。

• 里氏代換原則是實現開閉原則的重要方式之一，由於使用基類物件的地方都可以使用子類物件，因此在程式中儘量使用基類型別來對物件進行定義，而在執行時再確定其子類型別，用子類物件來替換父類物件。

      在使用里氏代換原則時需要注意如下幾個問題：

      (1)子類的所有方法必須在父類中宣告，或子類必須實現父類中宣告的所有方法。根據里氏代換原則，為了保證系統的擴充套件性，在程式中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的宣告，則無法在以父類定義的物件中使用該方法。

      (2) 我們在運用里氏代換原則時，儘量把父類設計為抽象類或者介面，讓子類繼承父類或實現父介面，並實現在父類中宣告的方法，執行時，子類例項替換父類例項，我們可以很方便地擴充套件系統的功能，同時無須修改原有子類的程式碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。

      在本例項中，可以考慮增加一個新的抽象客戶類Customer，而將CommonCustomer和VIPCustomer類作為其子類，郵件傳送類EmailSender類針對抽象客戶類Customer程式設計，根據里氏代換原則，能夠接受基類物件的地方必然能夠接受子類物件，因此將EmailSender中的send()方法的引數型別改為Customer，如果需要增加新型別的客戶，只需將其作為Customer類的子類即可。重構後的結構如圖2所示：

圖2  重構後的結構圖

      里氏代換原則是實現開閉原則的重要方式之一。在本例項中，在傳遞引數時使用基類物件，除此以外，在定義成員變數、定義區域性變數、確定方法返回型別時都可使用里氏代換原則。針對基類程式設計，在程式執行時再確定具體子類。

　　另外補充一篇關於里氏替換原則的一篇博文：

（4）依賴倒置原則

【作用】：依賴倒置原則要求我們在傳遞引數或關聯關係時，引用層次高的抽象層類，即使用介面和抽象類進行變數型別宣告、引數型別宣告、方法返回型別宣告以及資料型別的轉換等，而不使用具體類。為了確保該原則的應用，具體類應當只實現介面或父類中宣告的方法，而不含多餘的方法，否則將無法呼叫到子類中增加的新方法。

依賴注入：當一個物件要與其他物件發生依賴關係時，通過抽象來注入所依賴的物件。

實現方式：介面注入、構造器注入、設值注入

【例項】下面通過一個簡單例項來加深對依賴倒轉原則的理解：

      在本例項中，由於CustomerDAO針對具體資料轉換類程式設計，因此在增加新的資料轉換類或者更換資料轉換類時都不得不修改CustomerDAO的原始碼。我們可以通過引入抽象資料轉換類解決該問題，在引入抽象資料轉換類DataConvertor之後，CustomerDAO針對抽象類DataConvertor程式設計，而將具體資料轉換類名儲存在配置檔案中，符合依賴倒轉原則。根據里氏代換原則，程式執行時，具體資料轉換類物件將替換DataConvertor型別的物件，程式不會出現任何問題。更換具體資料轉換類時無須修改原始碼，只需要修改配置檔案；如果需要增加新的具體資料轉換類，只要將新增資料轉換類作為DataConvertor的子類並修改配置檔案即可，原有程式碼無須做任何修改，滿足開閉原則。重構後的結構如圖2所示：

圖2重構後的結構圖

      在上述重構過程中，我們使用了開閉原則、里氏代換原則和依賴倒轉原則，在大多數情況下，這三個設計原則會同時出現，開閉原則是目標，里氏代換原則是基礎，依賴倒轉原則是手段，它們相輔相成，相互補充，目標一致，只是分析問題時所站角度不同而已。

（5）介面隔離原則

【概念】這裡的“介面”往往有兩種不同的含義：一種是指一個型別所具有的方法特徵的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“介面”定義，有嚴格的定義和結構，比如Java語言中的interface。對於這兩種不同的含義，ISP的表達方式以及含義都有所不同：

      (1) 當把“介面”理解成一個型別所提供的所有方法特徵的集合的時候，這就是一種邏輯上的概念，介面的劃分將直接帶來型別的劃分。可以把介面理解成角色，一個介面只能代表一個角色，每個角色都有它特定的一個介面，此時，這個原則可以叫做“角色隔離原則”。

      (2) 如果把“介面”理解成狹義的特定語言的介面，那麼ISP表達的意思是指介面僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應當為客戶端提供儘可能小的單獨的介面，而不要提供大的總介面。在面向物件程式語言中，實現一個介面就需要實現該介面中定義的所有方法，因此大的總介面使用起來不一定很方便，為了使介面的職責單一，需要將大介面中的方法根據其職責不同分別放在不同的小介面中，以確保每個介面使用起來都較為方便，並都承擔某一單一角色。介面應該儘量細化，同時介面中的方法應該儘量少，每個介面中只包含一個客戶端（如子模組或業務邏輯類）所需的方法即可，這種機制也稱為“定製服務”，即為不同的客戶端提供寬窄不同的介面。

【例項】 下面通過一個簡單例項來加深對介面隔離原則的理解：

      在圖1中，由於在介面CustomerDataDisplay中定義了太多方法，即該介面承擔了太多職責，一方面導致該介面的實現類很龐大，在不同的實現類中都不得不實現介面中定義的所有方法，靈活性較差，如果出現大量的空方法，將導致系統中產生大量的無用程式碼，影響程式碼質量；另一方面由於客戶端針對大介面程式設計，將在一定程式上破壞程式的封裝性，客戶端看到了不應該看到的方法，沒有為客戶端定製介面。因此需要將該介面按照介面隔離原則和單一職責原則進行重構，將其中的一些方法封裝在不同的小介面中，確保每一個介面使用起來都較為方便，並都承擔某一單一角色，每個介面中只包含一個客戶端（如模組或類）所需的方法即可。

      通過使用介面隔離原則，本例項重構後的結構如圖2所示：

圖2 重構後的結構圖

     在使用介面隔離原則時，我們需要注意控制介面的粒度，介面不能太小，如果太小會導致系統中介面氾濫，不利於維護；介面也不能太大，太大的介面將違背介面隔離原則，靈活性較差，使用起來很不方便。一般而言，介面中僅包含為某一類使用者定製的方法即可，不應該強迫客戶依賴於那些它們不用的方法。

（6）迪米特法則

如果一個系統符合迪米特法則，那麼當其中某一個模組發生修改時，就會盡量少地影響其他模組，擴充套件會相對容易，這是對軟體實體之間通訊的限制，迪米特法則要求限制軟體實體之間通訊的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持鬆散的耦合關係。

      迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通訊等，在迪米特法則中，對於一個物件，其朋友包括以下幾類：

      (1) 當前物件本身(this)；

     (2) 以引數形式傳入到當前物件方法中的物件；

      (3) 當前物件的成員物件；

      (4) 如果當前物件的成員物件是一個集合，那麼集合中的元素也都是朋友；

      (5) 當前物件所建立的物件。

      任何一個物件，如果滿足上面的條件之一，就是當前物件的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個物件只能與直接朋友發生互動，不要與“陌生人”發生直接互動，這樣做可以降低系統的耦合度，一個物件的改變不會給太多其他物件帶來影響。

      迪米特法則要求我們在設計系統時，應該儘量減少物件之間的互動，如果兩個物件之間不必彼此直接通訊，那麼這兩個物件就不應當發生任何直接的相互作用，如果其中的一個物件需要呼叫另一個物件的某一個方法的話，可以通過第三者轉發這個呼叫。簡言之，就是通過引入一個合理的第三者來降低現有物件之間的耦合度。

      在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當儘量建立鬆耦合的類，類之間的耦合度越低，就越有利於複用，一個處在鬆耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當儘量降低其成員變數和成員函式的訪問許可權；在類的設計上，只要有可能，一個型別應當設計成不變類；在對其他類的引用上，一個物件對其他物件的引用應當降到最低。

     【例項】 下面通過一個簡單例項來加深對迪米特法則的理解：

      在本例項中，可以通過引入一個專門用於控制介面控制元件互動的中間類(Mediator)來降低介面控制元件之間的耦合度。引入中間類之後，介面控制元件之間不再發生直接引用，而是將請求先轉發給中間類，再由中間類來完成對其他控制元件的呼叫。當需要增加或刪除新的控制元件時，只需修改中間類即可，無須修改新增控制元件或已有控制元件的原始碼，重構後結構如圖2所示：