軟體設計原則

1、單一職責，

一個類應該隻有一個職責，否則耦合。

2、開閉原則，

可擴充不可修改，對于實在要修改的部分，用抽象隔離。

3、依賴倒轉原則

高層（調用者）不應該依賴于低層（被調用者），兩者都需要依賴于抽象；

抽象不應該依賴細節，細節應該依賴抽象（面向接口）

例子：業務類調用Sqlserver資料類，業務邏輯都封裝得很完美，然後此時有新項目了，需要用mysql，此時需要重寫mysql資料類，但是業務類完全可複用。那麼在新項目中，業務類移植過來後需要把調用SQL資料類的地方都改成調用mysql資料類。如果老項目中業務類調用的是接口，那麼新項目中mysql資料類隻要繼承接口，然後業務代碼完全可以不用動。

4、裡氏替換原則

把調用父類改為調用子類後，行為沒有任何改變。即子類必須能夠完全替代父類。

正是由于子類可以完全替換父類，才使得調用父類的子產品可以實作無限擴充。

例子：企鵝繼承鳥的話，就是違背了裡氏替換原則，因為鳥會飛，企鵝不會飛。

5、迪米特法則（最少知識原則）：隻與直接的朋友通信

如果兩個類不必直接通信，那麼就不應當發生直接的互相作用，如果需要調用另一個類的方法，可以通過第三者轉發調用。

原則：

a、盡量降低類和成員的可通路權限。

b、陌生類盡量不要作為局部變量出現的類的内部

c、直接的朋友是指有耦合關系：出現在成員變量、方法參數、傳回值中的類

缺點：過分使用會造成很多與業務無關的第三方類，降低通信效率。

優點：耦合度越低，複用率越高。

6、合成/聚合複用原則：盡量使用合成/聚合，盡量不使用繼承。

聚合表示一種弱擁有關系，A可以包括B，但B不是A的一部分；

合成表示強擁有關系，展現了 嚴格的部分和整體的關系，部分和整體的生命周期是一樣的。

比方：

鴿子有2隻翅膀，翅膀和鴿子則是合成關系。

鴿子屬于鴿群，鴿群有多個鴿子，鴿群和鴿子則是聚合關系。

好處：保證每個類都被封裝，并集中在單個任務上。這樣類的繼承規模會很小，不會增長為龐然大物。