設計模式的基本原則

設計模式是一套被反複使用、多數人知曉的，經過分類的、代碼設計經驗的總結

其目的是為了代碼可重用性、讓代碼更容易被他人了解、保證代碼可靠性

是解決方案，重心是思想，目的是為了讓代碼更簡便，簡潔，可靠，易了解，易複用，也就是常說的高内聚，低耦合

javascript中關于設計模式的基本原則，常見的有如下：

單一職責原則

最少知識原則

開放封閉原則

依賴倒置原則

一個類隻負責一個功能領域中的相應職責，在javascript中，使用到類的場景并不多，單一職責原則更多地運用在對象或者方法上

如果一個方法承擔過多的職責，那麼在需求的變遷過程中，需要改寫這個方法的可能性就會越大

單一職責原則是最簡單也是最難正确運用的原則，要明确的是，并不是所有的職責都應該一一分離：可參考 設計模式之單例模式

如果随着需求的變化，有兩個職責總是同時變化，那就不必分離他們

對象(函數、子產品等)應當盡可能少地與其他實體發生互相作用

在設計程式時，應當盡量減少對象之間的互動。如果兩個對象之間不直接通信，那麼這兩個對象就不要發生直接的互相聯系

常見的做法是引入一個第三者對象（中介者），來承擔這些對象之間的通信作用。如果一些對象需要向另一些對象發起請求，可以通過第三者對象來轉發這些請求。

javaScript設計模式中的使用最少知識原則的有：

中介者模式：通過增加一個中介者對象，讓所有的相關對象都通 過中介者對象來通信，而不是互相引用。是以，當一個對象發生改變時，隻需要通知中介者對象即可

外觀模式：對使用者屏蔽一組子系統的複雜性。為使用者提供一個簡單易用的接口，高層接口會把使用者的請求轉發給子系統來完成具體的功能實作

在面向對象的程式設計中，開放封閉原則是最重要的一條原則

其思想是當需要改變一個程式的功能或者給這個程式增加新功能的時候，可以使用增加代碼的方式，但是不允許改動程式的源代碼

開放指的是面向擴充開放：子產品的行為是能夠被擴充的。當應用程式的需求變化時，我們可以使子產品表現出全新的或與以往不同的行為，以滿足新的需求

封閉指的是面向修改封閉：子產品的源代碼不能被侵犯，任何人都不允許修改已有的源代碼

該方法用起來是可以的，但是如果想要添加功能，就需要往函數内部添加case，這樣也會導緻整個 API 變得臃腫，難維護，違反封閉開放原則

可以改造成如下：

高層次的子產品不應該依賴于低層次的子產品，他們都應該依賴于抽象，抽象不應該依賴于具體實作，具體實作應該依賴于抽象

例如人吃東西， 可以吃米飯、饅頭、面條等等，這裡人就是高層的子產品，人要活着就需要依賴吃的行為

吃的行為是一個抽象的行為，可以米飯、饅頭等等

而不能變成人要依賴吃米飯或者吃饅頭

這樣則降低了客戶與實作子產品間的耦合

讓程式一開始就盡量遵守開放-封閉原則，并不是一件很容易的事情，需要預測容易變化的部分

挑選出最容易發生變化的地方，然後構造抽象來封閉這些變化

在不可避免發生修改的時候，盡量修改那些相對容易修改的地方。例如用修改配置檔案，代替修改它的源代碼

參考文章：https://mp.weixin.qq.com/s/Uhx7GBqwhoZ5bhbi94StAA