【譯】設計？模式？咱們在軟件開發中仍然考慮嗎？

確定的。

在面向對象編程中，咱們，開發者們，努力去把咱們的世界模型化。如此，嘗試和使用周圍的世界做爲一種描述咱們的創造的工具是有意義的。

• 單例模式
  • 是什麼
  • 爲何
  • 哪裏用
• 觀察者模式
  • 是什麼
  • 爲何
  • 哪裏用
• 外觀模式
  • 是什麼
  • 爲何
  • 哪裏用
  • 從這裏來，到哪裏去

在這種狀況下，咱們從建築（就是寫建築物和橋樑的那個）中選取一頁，這本書有深遠影響的建築書籍叫【模式語言：鄉鎮，建築，構造】，由 Christopher Alexander，Sara Ishikawa，Murray Silverstein 撰寫，這裏模式是這樣描述的：

每一個模式描述了一個在咱們環境中不斷髮生的問題，同時描述了問題解決方案的核心，這種方式下你可使用數千次這樣的解決方法。不用一樣的方式重複兩次。

在軟件開發中，建築是用健康，健壯和可維護的方式構造的過程，而且模式提供了一種命名方法去解決常見問題。這些解決方案從抽象/形象到十分精確和專業中變化，而且讓開發者有效的相互交流。

若是團隊中兩個或者更多開發者都有關於模式的認識，討論問題的解決方案將會變得十分高效。若是隻有一個開發者瞭解模式，那麼跟團隊的其餘人員解釋一般是簡單的。

這篇文章的目的在於經過給你介紹軟件設計模式的概念和展現一些有趣的在如今 JavaScript 項目中大量使用的模式來激發你對軟件開發中一些正式表示的知識。

單例模式

是什麼

單例模式並非最普遍使用的，可是咱們從這裏開始是由於它比較好理解。

單例模式來源於單例的數學概念，以下：

在數學中，一個單例，也就是一個單元集，是一個肯定元素的集合。好比：集合 {null} 是一個單例。

在軟件中，簡單解釋爲，咱們爲單個對象限制了類的實例。單例模式實現類的對象第一次應該被實例化，它實際上會獲得實例。任何隨後的實例化嘗試將會返回第一個實例。

當蝙蝠俠在這裏，誰會須要兩個超級英雄呢？

爲何

除了咱們只能擁有一個超級英雄時（蝙蝠俠顯然是），爲何咱們會使用單例模式？

雖然單例模式自己沒有問題（它以前被稱做騙子，如今叫作惡魔），它仍然有本身的用處。最顯著的是它能夠做爲配置對象的實例。你可能只須要在應用中有一個配置實例，除非提供多個配置是應用的特性。

哪裏用

Angular 服務是單例模式在流行框架中使用的最好的例子。這篇文章在 Angular 文檔中解釋瞭如何確保服務始終是做爲單例使用的。

單例服務有不少意義，由於服務用來儲存狀態，配置和容許組件交流，同時你想去肯定沒有多個實例搞亂這些概念。

做爲例子，假設你有一個不重要的應用用來統計按鈕的點擊次數：

你應該保持按鈕點擊的數量的追蹤，在一個對象裏提供：

• 計數功能
• 提供當前點擊數

若是對象不是單例模式（按鈕有他們本身的實例），點擊就不會正確。並且，哪個計數實例是你提供組件展現當前計數的？

觀察者模式

是什麼

觀察者模式定義以下：

觀察者模式在軟件設計模式中這樣定義，一組叫作主題的對象，維護它的依賴列表，叫作觀察者，同時自動通知它們任何狀態改變，一般經過調用它們的方法。

觀察者模式十分容易理解，若是咱們跟真實世界的例子比較——報紙訂閱。

一般可能發生的狀況是，當你購買一份報紙，須要走到報刊亭，詢問你喜歡的報紙的新期刊是否出版。若是沒有，這是一個無效的糟糕狀況，你不得不走回家過一會再來試試。在 JavaScript 術語中，狀況相似，當不斷輪詢直到你獲得本身想要的。

當你最後獲得報紙，整個時間你能夠作想作的——坐下來品嚐咖啡看看報紙（一樣，在 JavaScript 中，能夠執行你一直想要的回調函數）。

最終

聰明一點的作法（天天獲得你最愛的報紙）是訂閱這個報紙。

這種方式，當報紙的新期刊出版時，發行公司會通知你而且把報紙投遞給你。不須要再跑到報刊亭。不須要在失望。狂歡吧。

在 JavaScript 中，你再也不須要循環請求結果直到你運行函數。你能夠，替代地，讓主題知道你對一些事件（消息）感興趣，而後提供一個回調，它會在新數據準備好後通知你。這時候，你就是觀察者。

用不在早上錯過報紙

最棒的事情在於——你不必定是惟一的訂閱者。當你因錯過報紙而沮喪時，其餘人也是。這就是爲何多個觀察者能夠訂閱這個主題。

爲何

觀察者模式有不少使用場景，可是一般，它應該被用於當你但願建立一對多的依賴，在對象沒有緊密結合的對象間，同時可能讓不定數量的對象知道什麼時候狀態改變。

JavaScript 對觀察者模式來講是個好地方，由於一切都是事件驅動，而不是總在詢問是否事件發生了，你應該讓事件通知你（像是一句古老諺語：「不要電話咱們，咱們會電話你」）。

有可能你已經作了一些像觀察者模式的事——addEventListener。給元素添加事件監聽具有全部觀察者模式的特徵：

• 你能夠訂閱一個對象
• 你能夠取消訂閱一個對象
• 對象能夠對全部訂閱者廣播

學習觀察者模式的最大優點在於你能夠實行本身的主題或者更快抓住一個已經存在的解決方案。

哪裏用

實現一個基本的觀察者並不困難，不過這裏有個很棒的庫用於不少項目，它是 ReactiveX，它的 RxJS 是 JavaScript 版的。

RxJS 容許你不只訂閱主題，並且提供任何能想象的方式的轉換數據的可能，組合多個訂閱，處理異步工做更容易和不少不少其餘的。若是你曾經想讓你的數據處理和轉換過程更上一級，RxJS是一個不錯的學習的庫。

除了觀察者模式，ReactiveX 爲實現了迭代器模式而自豪，它讓主題可能知道它的訂閱者什麼時候訂閱結束，從而有效地結束了主題訂閱。這篇文章中我不解釋什麼是迭代器模式，它是個不錯的練習，讓你學習更多同時看看如何適應觀察者模式。

外觀模式

是什麼

外觀模式的名字取自建築學。在建築學中：

外觀一般是建築的外部一側，通常是前部。這是來自法語，它的意思的「正面」或者「臉部」。

在建築學中的外觀是指建築的外表，隱藏了內部的工做，軟件開發的外觀模式試着隱藏在正面之下深層的複雜，有效地讓你經過 API 工做，這樣當你想去改變隱藏代碼時提供了改變的可能。

爲何

你能夠在各類場景下使用外觀模式，可是最顯著的一個場景是讓你的代碼更容易理解（隱藏複雜）同時讓依賴儘量鬆耦合。

哦呀咔！

很容易看到爲何外觀對象（或多對象層）是一件很棒的事。若是能避免，你不會想去面對惡龍。外觀對象將給你提供不錯的 API，同時處理全部惡龍本身的鬼把戲。

另外不錯的事是咱們在這裏能夠改變惡龍的外觀，從沒有接觸其他應用的背景之中。假如你想用小貓來改變龍的外觀。它仍然有爪子，可是更容易餵養。改變外觀要重寫一些代碼，在外觀下不須要改變任何依賴的對象。

哪裏用

你常常看到外觀的地方是 Angular 使用它的服務做爲簡單的背景邏輯。但不止是 Angular，下面的例子你也會看到。

若是說你想給本身的應用添加狀態管理。你能夠試試 Redux，NgRx，Akita，MobX，Apollo或者任何新流行的東西。那麼，爲何不選擇它們帶它們兜兜風？

基本功能的狀態管理庫提供了什麼給你？

可能有：

• 一種讓狀態管理指導你想去改變狀態的方式
• 一種得到當前狀態的方式

聽起來不差。

如今，在你揹帶下用外觀模式的力量，你能夠爲狀態的每一個部分修改外觀，這些狀態將會提供一個不錯的 API 爲你工做——好比像，facade.startSpinner(), facade.stopSpinner(),facade.getSpinnerState()。這些方法容易理解和分析緣由。

以後，你能處理外觀，修改代碼，讓代碼轉換成在 Apollo 下有效的（用 GraphQL管理狀態——如此正確）。你或許注意到它一點不適合你的代碼方式，或者單元測試的方式不得不從新修改。沒關係，寫一個新的外觀，來支持 MobX。

或許也是一條龍

從這裏來，到哪裏去

你可能注意到咱們沒有討論過設計模式的代碼實現。這是由於每一種設計模式在書中至少是一章內容。

如今咱們來看看這些書，看看一兩本深刻的設計模式不會有什麼壞處。

首先要推薦的是 設計模式：可複用的面向對象軟件的基礎，一堆大佬寫的。這書有黃金屋的，軟件設計模式的聖經。

若是你在找更簡單的那麼：head first 設計模式系列也不錯。

但不止這些，試着搜索，讀讀不一樣的實現。即便你歷來沒有使用過模式或者技巧，你也能學到一些東西，在沒有預料的方式下成長。