六大設計原則
單一職責原則（Single Responsibility Principle，SRP）
定義：應該有且僅有一個原因引起類的變更
意義：
- 類的復雜性降低，實作什么職責都有清晰明確的定義
- 可讀性提高
- 可維護性提高
- 變更引起的風險降低
使用注意：
- 是一種很難衡量的模式，需要根據具體業務來，而不是越細越好
- 需要衡量可變因素和不可變因素，以及相關的收益成本比率
- 介面一定要做到單一職責，類的設計盡量做到只有一個原因引起變化
里氏替換原則(Liskov Substitution Principle, LSP)
定義：
- 如果對每一個型別為S的物件o1，都有型別為T的物件o2，使得以T定義的所有程式P在所有的物件o1都代換成o2時，程式P的行為沒有發生變化，那么型別S是型別T的子型別，
- 所有參考基類的地方必須能透明地使用其子類的物件
所有參考父類的地方，換成父類的任意子類都可以正常作業
里氏替換原則對繼承的規范要求：
- 子類必須完全實作父類的方法
- 子類可以有自己新的方法
- 覆寫或實作父類的方法時輸入引數可以被放大（引數型別 范圍放大）
- .覆寫或實作父類的方法時輸出結果可以被縮小（回傳型別可以為父類方法的子型別）
依賴倒置原則(Dependence Inversion Principle,DIP)
定義：
- 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象
- 抽象不應該依賴細節
- 細節應該依賴抽象
在java中的表現：
- 模塊間的依賴通過抽象發生，實作類之間不發生直接的依賴關系，其依賴關系是通過介面或抽象類產生的
- 介面或抽象類不依賴于實作類
- 實作類依賴介面或抽象類
實質就是面向介面編程
意義：
- 可以減少類間的耦合性
- 提高系統的穩定
- 降低并行開發引起的風險
- 提高代碼的可讀性和可維護性
作者在這里使用了一個司機、寶馬、奔馳的例子進行了闡述，
依賴的三種方法：
- 建構式傳遞依賴物件
- setter方法注入依賴物件
- 介面宣告依賴物件，也叫介面注入（其實就是在呼叫方法時傳入依賴物件）
介面隔離原則（Interface Segregation Principle, ISP）
定義：
- 客戶端不應該依賴它不需要的介面
- 類間的依賴關系應該建立在最小的介面上
建立單一介面，不要建立臃腫龐大的介面，即介面盡量細化，同時介面中的方法盡量少
違背介面隔離原則的壞處：
書中舉了一個美女介面，并以美女標準變更說明了將多個方法放到一個介面難以適應變化
介面隔離原則對介面設計規范的要求：
- 介面要盡量小
- 介面要高內聚
- 定制服務
- 介面設計是有限度的
迪米特法則（Law of Demeter，LoD）或最少知識原則（Least KnowledgePrinciple，LKP）
定義：
一個物件應該對其他物件有最少的了解
意義：
解耦，方便維護
原則：
- 只與直接依賴的物件通信
- 物件之間的依賴應該盡可能少的暴露內部細節
開閉原則（Open Close Principle， OCP）
定義：
一個軟體物體如類、模塊和函式應該對擴展開放，對修改關閉，
開閉原則告訴我們應盡量通過擴展軟體物體的行為來實作變化，而不是通過修改已有的代碼來完成變化
意義：
有助于構建穩定的、靈活的系統
開閉原則的案例：
書中給出了銷售書的一個案例，變化是需要打折，此時如何處理的問題，給出的最優方法是繼承原來的書，重寫其getPrice方法
使用開閉原則的原因：
開閉原則是最基礎的一個原則，其他設計原則都是開閉原則的具體形態，也就是說其他原則就是指導設計的工具和方法，而開閉原則才是其精神領袖
開閉原則的重要性體現：
- 開閉原則對測驗的影響
- 開閉原則可以提高復用性
- 開閉原則可以提高可維護性
- 面向物件開發的要求
如何使用開閉原則：
- 抽象約束
- 通過介面或抽象類約束擴展，對擴展進行邊界限定，不允許出現在介面或抽象類中不存在的public方法
- 引數型別、參考物件盡量使用介面或者抽象類
- 抽象層盡量保持穩定，一旦確定即不允許修改
- 元資料（metadata）控制模塊行為
用來描述環境和資料的資料，通俗地說就是配置引數，引數可以從檔案中獲得，也可以從資料庫中獲得
-
制定專案章程
-
封裝變化
- 將相同的變化封裝到一個介面或抽象類中
- 將不同的變化封裝到不同的介面或抽象類中，不應該有兩個不同的變化出現在同一個介面或抽象類中
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/184529.html
標籤：Java