面向對象的設計原則

1 軟件設計中存在的問題

1)過于僵硬(Rigidity):很難加入新功能
2)過于脆弱(Fragility):很難修改
3)復用率低(Immobility):高層模塊無法復用
4)黏度過高(Viscosity): 破壞原始框架的設計

2 好的設計的目標

1)可擴展性(Extensibility):容易添加新的功能而不影響已有模塊
2)靈活性(Flexibility):代碼修改平穩地發生，一處修改不影響另一處
3)可插入性(Pluggability):容易將一個類抽出去，同時將另一個有同樣接口地類加入進來， 而不想象類的使用者

3 面向對象的設計原則

1)“開－閉”原則(The Open-Closed Principle):對可變性地封裝
* Open for extension, closed for modification
* 通過增加代碼來變化， 而不是更改現有代碼來變化
* 封裝可變性， 抽象出抽象體，此抽象體不可更改，但可以通過派生抽象體來擴展功能。

2)里氏替換原則(The Liskov Substitution Principle):如何進行繼承
* 若用類S對象替換類T對象后程序的功能不變，則S是T的子類型
* OOD中的Is-A關系是就行為功能而非內在關系而言, 其繼承概念與通常的數學法則和生活常識是不同范疇的事物， 有不可混淆的區別
* 在任何父類出現的地方都可以用它的子類來替代

3)依賴倒置原則(Dependence Inversion Principle):針對接口編程
* 高層模塊不應該依賴于低層模塊。二者都應該依賴于抽象。
* 抽象不應該依賴于細節，細節應該依賴于抽象。
* 類之間的耦合關系：零耦合(Nil Coupling),具體耦合(Concrete Coupling),抽象耦合(Abstract Coupling)
* 從問題的具體細節中分離出抽象，以抽象方式對類進行耦合。
* 但會導致產生大量的類

4)接口隔離原則(Interface Segregation Principle) 恰當地劃分角色和接口
* 從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小的接口上的。使用多個專門的接口比使用單一的總結口要好。

5)合成/聚合復用原則(Composite/Aggregate Reuse Principle):盡量使用合成/聚合而不使用繼承
* 聚合： 表示擁有或整體與部分的關系。UML中意為shared(Aggregate), 用空心菱形表示
* 合成：更強的聚合關系。整體負責部分的生命周期，整體和部分是不可分的，部分是不能被共享的。比如孫悟空 ，他的四肢， 和他的武器。悟空和四肢的關系就是合成，而和武器之間的關系就是聚合。UML中意為composite, 用實心菱形表示
* 在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新的對象通過向這些對象的委派達到復用這些對象的目的。
* 繼承優點:新的實現較為容易; 比較容易添加到已有系統中
  繼承缺點：破壞封裝; 很難處理超類的變化; 繼承的實現是靜態的
* 聚合優點：支持封裝; 支持包裝; 復用可以動態進行
  聚合缺點: 不易擴展已有系統; 需要較多的對象管理

6)最少知識法則(Law of Demeter): 不要和陌生人說話
* 只和你直接的朋友們通信，不要和"陌生人"說話
* 一個對象應當對其他對象有盡可能少的了解
* 其目的就是降低各個單元的耦合，提高系統的可維護性。如Facade, Mediator模式

7) 單一職責原則(Single Responsibility Principle): 把耦合消滅在萌芽狀態
* 就一個類而言,應該僅有一個引起它的變化的原因
* 在SRP中，　職責被定義為“變化的原因”
* 如果一個類承擔的職責過多，導致職責耦合，一個職責的變化可能會削弱或者抑制這個類完成其它職責的能力。
* 一個職責變化引起該類關于該職責的接口的變化會導致所有使用該類其它職責的客戶重新編譯。
* 一個職責可能使用了一些庫，導致這個類的其它職責的客戶雖然不需要該功能卻又不得不引入這些庫。