設計模式整理--面相對像設計原則

一、設計模式原則：

1、單一職責原則：

具體描述：應該有且僅有一個原因引起類的變更，即一個方法儘可能只做一件事，儘可能只實現一個功能，而介面儘可能只負責一類功能描述，而類的設計儘量做到只有一個原因引起變化。

實現好處：

降低類複雜性，實現什麼職責都有清晰明確的定義，提高了可讀性，更進一步地提高可維護性，且降低了變更引起的風險。因為一個變化只有一個原因引起，所以變化引起的變更只修改一個地方便可。

2、里氏替換原則：

具體描述：

所有引用基類的地方必須能透明地使用其子類的物件。即只要父類能出現的地方，子類就可以出現，且替換為子類不會發生任何錯誤或異常，而使用者可能根本不需要知道是父類還是子類但是反過來就不可以，有子類出現的地方，父類未必可以適應。

一般，子類必須完全實現父類的方法，但子類可以有自己的個性。

實現好處：

使用里氏替換原則的目的是增強程式的健壯性，版本升級時也可以保持非常好的相容性，即使增加子類，原有的子類還是可以繼續執行，在實際應用中，每個子類對應不同的業務含義，使用父類作為引數，傳遞不同的子類則可以完成不同的業務邏輯。當然，要使用子類的“個性化”業務邏輯，必須建立子類的物件，不過採用里氏替換原則設計類時，應儘量避免子類的“個性化”。

注意：覆蓋或實現父類的方法時，輸入引數可以被放大，所以應該使子類中的方法的前置條件必須與超類中被覆寫的方法的前置條件相同或更寬。

覆寫或實現父類的方法使輸出結果可以被縮小。

3、依賴倒置原則：

具體描述：高層模組不應該依賴底層模組，兩者都應該依賴其抽象，抽象不該依賴實現細節，細節應該依賴於抽象，即，模組間的依賴通過抽象發生，實現類之間不發生直接依賴關係，其依賴關係式通過介面或抽象類產生，而介面或抽象類不依賴於實現類，實現類則依賴於介面或抽象類。

物件的依賴關係有以下方式來傳遞：

A、建構函式傳遞依賴物件，即在類中通過建構函式宣告依賴物件。

B、通過函式傳遞，即將介面作為引數來傳遞

C、介面宣告物件依賴，即通過宣告介面來產生依賴

一般實現：

A、每個類儘量都有介面或抽象類或者抽象類和介面兩者都具備

B、變數的表面型別儘可能是介面或者抽象類

C、任何類都不應從具體的實現類派生

D、儘量不要覆寫基類的方法

E、結合里氏替換原則使用，即介面負責定義public屬性和方法，並且宣告與其他物件的依賴關係，抽象類負責公共建構函式的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化，但儘量避免子類的“個性化”。

一般在實際專案中，對大型的專案採用依賴倒置原則可以讓維護輕鬆，擴充套件容易簡單。

4、介面隔離原則：

具體描述：

客戶端不應該依賴它不需要的介面，儘可能的保持介面的純潔性，而類間的依賴關係應該建立在最小的介面上，即建立單一的介面，使介面儘量細化，同時介面中的方法儘量少。

一般實現：

A、介面要儘量的小，但不能違反單一職責

B、介面要高內聚，即提高介面、類、模組的處理能力，減少對外的互動，使其各司其職，但又相互配合。即在介面中儘量少公佈子類的public方法，介面是對外的承諾，承諾越少對系統開發越有利，變更的風險也就越少，同時有利於降低成本。

C、定製服務，即單獨為一個個體提供有利的服務，具體點就是隻提供訪問者需要的方法。

D、介面設計的粒度是有限度的，在可維護和開發的前提下，儘可能地使設計粒度小，從而使系統更靈活。

     一般在實際專案中，介面和類儘量使用原子介面或原子類來組裝，使一個介面只服務於一個子模組或業務邏輯，通過業務邏輯壓縮介面中的public方法，時常回顧介面，儘量減小其粒度，但若已經被耦合化，或過多耦合的介面，儘量去修改，但若變更風險太大，則嘗試用介面卡模式進行轉化處理。不過也不要生搬亂套，要了解環境，拒絕盲從，深入業務邏輯，針對業務邏輯設計介面。

5、迪米特法則：

具體描述：

   一個物件應該對其他物件有最少的瞭解，或一個類應該對自己需要耦合或呼叫的類知道得最少。

一般實現：

    物件間，只和相互之間直接耦合的類通訊，在設計時應該反覆衡量是否可以再減少Public方法和屬性，是否可以改為其他的諸如private,protected等訪問許可權，是否可以加上final等。如果一個方法放在本類中，即不增加類間關係，也對本類不產生負面影響，就放置在本類中。謹慎使用Serializable,迪米特法則的核心觀念就是類間的解耦，弱耦合，類的複用率才可以提高，但解耦就意味和產生中專或跳轉類，同時是系統的複雜性提高，同時也維護帶來難度，所以使用此法則時需反覆權衡，即做到讓結構清晰，又做到高內聚低耦合。

6、開閉原則：

具體描述：

一個軟體實體如類、模組和函式應該對擴充套件開發，對修改關閉。

一般實現：

   儘可能使用擴充套件軟體實體（專案或軟體產品中按照一定的邏輯規劃劃分的模組，或抽象和類，方法），而不是通過修改已有的程式碼來完成變化，也就是說在設計時就該預留或提供可擴充套件的介面，或方法，一般的變化可歸納為邏輯變化，子模組變化，可見檢視變化。

開閉原則的好處：

A、對測試的影響：新增加的類，新增加的測試方法，只要保證新增加的類的正確性就好。

B、提高複用性

C、提高維護性

如何使用：

A、抽象約束，即通過介面或抽象類約束擴充套件，對擴充套件進行邊界界定，不允許出現在介面或抽象類中不存在的public方法，同時引數型別、引用型別儘量使用介面或抽象類，而不是實現類，在設計時確保抽象層的穩定性，一旦確定了，就不可以改了。

B、後設資料控制模組行為，即用描述環境和資料的資料，或配置引數，引數可以從檔案或資料庫中獲得。

C、制定專案章程：團隊間制定相關規範，使成員必須或儘可能遵守。

D、封裝變化：將相同的變化封裝到一個介面或抽象類中，將不同的變化封裝到不同的介面或抽象類中，不該有兩個不同的變化出現在同一個介面後抽象類中。