設計原則
💡 充分理解設計原則，更能讓你理解設計模式背後的概念。
原則一 單一職責 SRP2
一個類別或物件，只做一件事情
但需要在方便與穩定性中取得平衡，有時即使一開始兩個職責寫再一起，但是不會變動，可以等重構時再拆分。
優缺：職責需要變動時不會影響到其他地方，有利重用與單元測試。 缺點：增加編寫程式碼的複雜度，增大物件之間相互聯繫的難度。
原則二 開放／封閉原則 OCP
軟體實體應可擴展，但是不可修改
原則是當要修改原始碼時，不去直接修改，而是利用增加其他功能的方式，與就功能做耦合，維持舊埕式的穩定度；也可以將舊程式改為物件的多態性，來創建新的物件。
但過多運用此原則，會造成過多的抽象層次，增大程式複雜度。
因此可以：
- 掏選最容易發生變化的地方，構造抽象來封閉變化。
- 盡量修改相對容易的地方，例如設定檔，而非原始碼。
原則三 Kiskov替換原則 LSP
子類別可以替換掉父類別，而程式架構功能不受影響
雖然大部分的例子都是講到繼承，但是在Javascript中我們可以注重類別的行為，當一個方法體現另一個方法時，就要注意這項原則。
如何解決違反的情形：
- 利用前置條件與後置條件來確認子類別沒有超出或減少父類別
- 減少繼承，當有繼承發生時，確認行為沒有改變，或是兩個根本應該是多型
原則四 介面隔離原則 ISP
模組間的依賴不應有用不到的功能
簡單來理解就是，父類別的動作太多，子類別繼承如果不會的話還假會，不如把動作丟到別的介面，讓子類別真的會的去繼承介面就好了。
但在JS中比較少需要使用到這種狀況，因為JS中少用繼承。
原則五 依賴反轉原則 DIP
高階模組不依賴低階模組，而應都依賴抽象
有點複雜，直接參考 汤姆大叔
Comments