Java設計模式 -- 基本原則

開始系統地學習設計模式相關的知識，對每一個原則或者設計模式主要從下面幾點分析學習：

• 定義：簡單地描述其作用
• 解決問題：說明該原則或設計模式解決什麼限制條件下的問題。
• 結構圖：繪制相關例子的UML機構圖。
• 代碼示例：通過一個例子解釋該模式的實現方法。
• 優缺點：該模式的局限性。

單一職責原則(Single Responsibility Principle)

定義：
一個類只負責一個功能領域的職責；換句話說，就一個類而言，應該只有一個引起它變化的原因。

注意：

• 職責擴散是單一職責的挑戰，應在其擴散到不可控制之前進行代碼重構。
• 只有在邏輯足夠簡單或者方法數量足夠少，才能夠違反單一職責
• 單一職責的優點主要是：降低類的復雜度，提高類的可讀性和可維護性。

例子：
重構前：

重構後：

• 在CustomerDataChart中定義了多種功能，例如數據庫連接、查詢顧客、顯示圖標多個職責。
• 可以將其進行分解成三個類，分別負責不同的職責。

開閉原則(Open-Closed Principle)

定義：
軟件實體應該對擴展開放，對修改關閉。

注意：

• 抽象化設計是開閉原則的關鍵：用抽象類構架框架，用實現擴展細節。
• 其它原則和設計模式的整體概括，該原則是主要目標。

例子：
重構前：

重構後：

• 先前使用type作為顯示圖類型的判斷因子，如果新增一種圖，則需要修改ChartDisplay類，違反了向修改封閉的原則。
• 重新構建一個抽象類AbstractChart類，所有圖像顯示都需繼承實現抽象類，如果有新的顯示類只需要擴展一個新類，而不需要修改ChartDisplay類，符合向擴展開放的原則。
• 這個重構同時也符合依賴倒置的原則，使客戶端程序不需要依賴具體實現，而是依賴抽象。
• 但是這個重構需要客戶端知道所有顯示圖像類。

裡氏代換原則(Liskov Substitution Principle)

定義：
所有引用基類(父類)的地方必需能夠透明地使用子類對象。

注意：

• 將一個基類替換成其子類，程序不會產生任何錯誤和異常；反之則不成立。
• 裡氏代換原則要求不能破壞繼承體系，具體表現在：
  1. 子類應該實現父類的所有抽象方法，不要覆蓋父類的非抽象方法。
  2. 子類可以增加自己特有的方法。
  3. 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
  4. 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

例子：
重構前：

重構後：

• 重構前，有大量的代碼重復，如果增加新的用戶，則需要維護EmailSender。
• 重構後，利用裡氏替換原則，能夠使用Customer基類的地方，都可以替換為其子類，方便擴展。

依賴倒置原則(Dependency Inversion Principle)

定義：
抽象不依賴於細節，細節依賴於抽象，針對接口編程。

注意：

• 在程序代碼中傳遞參數或者關聯關系式，盡量引用高層的抽象層類。即：使用接口和抽象類進行變量生命、參數類型生命、方法返回類型生命以及數據類型的轉換。
• 當一個對象和其它對象有依賴關系時，可以利用依賴注入的方法將類之間進行解耦。主要有三種：構造注入，Set方法和接口注入。
• 上述三個原則之間的關系：開閉是原則，裡氏是基礎，依賴倒置是手段。

參考資料：
深入理解依賴注入

例子：
重構前：

重構後：

• 重構前如果需要更改不同的DataConvertor就需要更改CustomerDAO的源碼。
• 重構後可以直接利用配置文件指定哪個類，並不需要修改代碼。

接口隔離原則(Interface Segregation Principle)

定義：
使用多個專門的接口，而不是使用功能復雜的單一接口。

注意：

• 控制接口的粒度，接口不能太小，如果太小會導致系統中接口泛濫，不利於維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。

例子：
重構前：

重構後：

合成服用原則(Composite ReSUSE Principle)

定義：
又稱為組合/聚合復用原則(Composition/Aggregate Reuse Pinciple)，盡量使用對象組合，而不是繼承來達到復用的目的。

注意：

• 組合/聚合可以降低類之間的耦合度，並且不會暴漏類的具體實現細節，稱為“黑箱復用”；如果是使用繼承機型復用，則會將實現細節暴漏給子類，破會系統的封閉性，如果基類變化，子類也隨之變化，不具有靈活性，稱為“白箱復用”。
• 一般來說，如果兩個類之間是"Has-A"關系，則使用組合/聚合；如果是"Is-A"關系，則使用繼承。

例子：
重構前：

重構後：

迪米特法則

定義：
一個軟件實體應當盡可能少地與其它實體發生相互作用。

注意：

• 可以直接相互的作用包括：
  1. 當前對象本身，this。
  2. 以參數形式傳入到當前對象方法中的對象。
  3. 當前對象的成員對象。
  4. 如果當前對象的成員對象是一個集合，那麼集合中的元素也都可以直接訪問。
  5. 當前對象創建的對象。
• 如果其它對象有相互耦合的情況，盡量采用第三者來降低耦合。

例子：
重構前：

重構後：

• 重構前各個實體相互作用關系復雜，不利於項目維護。
• 重構後將所有實體的操作和調用信息都交由Mediator進行中轉，利於軟件功能擴展和維護。