軟件設計原則

開發人員的五個信條：

讓代碼更靈活，讓軟件更健壯，讓開發更快樂...

1. 單一職責原則

• 此意何解

  就一個類而言，應該僅有一個引發它變化的緣由。

• 知識點

  1. 若是一個類承擔的職責過多，就等於把這些指責偶合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其餘職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
  2. 軟件設計真正要作的許多內容，就是發現職責並把那些職責相互分離。

---

2. 迪米特法則

• 此意何解

  若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。

• 知識點

  1. 最少知識原則。
  2. 在類的結構設計上，每個類都應當儘可能下降成員的訪問權限。
  3. 迪米特法則的根本思想是，強調類之間的鬆耦合。類之間的耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類形成波及。

---

3. 開發-封閉原則

• 此意何解

  對於擴展是開放的，對於修改是封閉的。

• 知識點

  1. 開發-封閉原則是面向對象設計的核心。可維護、可複用、可擴展、靈活性好
  2. 面對需求，對程序的改動是經過增長新代碼進行的，而不是更改現有的代碼。
  3. 開發人員應該僅對程序中呈現出頻繁變化的那些部分作出抽象，然而，對於應用程序中的每個部分都刻意的進行抽象一樣不是一個好主意。拒接不成熟的抽象和抽象自己同樣重要!

---

4. 依賴倒轉原則

• 此意何解

  • 高層模塊不該該依賴低層模塊。兩個都應該依賴抽象。
  • 抽象不該該依賴細節。細節應該依賴抽象。

• 知識點

  1. 依賴倒轉是面向對象設計的標誌
  2. 針對接口編程，不要對現實編程。
  3. 抽象應該依賴細節，細節不該該依賴於抽象。
  4. 程序中全部的依賴關係都是終止於抽象類或者接口，那就是面向對象的設計，反之就是過程化設計。

---

5. 裏式替換原則

• 此意何解

  子類型必須可以替換掉它們的父類型。（一個軟件實體若是使用的是一個父類的話，那麼必定適用於其子類，而其它察覺不出父對象和子對象的區別。也就是說，在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化）

• 知識點

  1. 只有當子類能夠替換掉父類，軟件單位的功能不受到影響時，父類才能真正的被複用，而子類也可以在父類的基礎上增長新的行爲。
  2. 因爲子類型的可替換性才能使得父類型的模塊在無需修改的狀況下就能夠擴展。