設計模式漫談

前言

随着程式設計經驗的增加，慢慢的發現基本的文法知識已經掌握，也能解決一些問題。但，總感覺自己編寫的代碼品質不高，可維護性不強，為了解決這個問題，就看了一些關于程式設計風格、程式設計規範、設計模式等方面的書籍和文章。總的來說，收獲頗多。本文旨在對設計模式進行粗淺的介紹，後續會陸續介紹JS裡常用的設計模式。

1.為什麼使用模式？

模式是一種可複用的解決方案，可用于解決軟體設計中遇到的常見問題。那麼設計模式會給我們的程式設計實踐帶來什麼助益呢？下面就是設計模式的優點：

• 模式是已經驗證的解決方案

設計模式（Design pattern）是一套被反複使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，它們為解決軟體開發中遇到的問題提供了可靠的方法。

• 模式很容易被複用

模式是被驗證過的解決方案，可以立即使用，可以結合自己的開發需求使用這些模式。

• 模式富有表達力

使用設計模式是為了可重用代碼，讓代碼更容易被他人了解、保證代碼可靠性。

• 複用模式有助于防止在應用程式開發過程中小問題引發大問題

當我們在已驗證的模式基礎上開發代碼時，可以在代碼結構上花費更少的精力，更多的關注整體解決方案。因為模式支援我們用更結構化、更有組織性的方式編寫代碼，進而避免以後因代碼的整潔性問題而重構代碼。

• 模式可以提供通用的解決方案，并且其記錄方式不需要與某個特定問題挂鈎

模式是通用性的，不局限于具體的項目和程式設計語言。

• 某些模式确實能夠通過避免代碼複用來減少代碼的總體資源占用量

某些模式可以更多的複用代碼，減少代碼量，而且代碼結構也更加緊湊和嚴密，具有更強的可讀性和可維護性。

• 模式添加到開發人員的詞彙中，會使溝通更快速

• 經常使用的模式可以逐漸改進，因為其他開發人員會及時回報

2.何為設計模式？

設計模式有其自身的要求與規則，并不是每一種算法、最佳實踐或解決方案都代表一種完整的模式。在尚未被審查之前，設計模式社群通常不會認定它是一種真正的設計模式。即使某種内容外觀看起來符合模式的标準，但這依然需要經過一段時間的審查和多人的測試，隻有這樣才能成最終的設計模式。

設計模式應該是一種流程，也是一種事物，是一種能夠建立“事物”的流程。

原始模式：一種尚未通過“模式”測試的設計模式。原始模式是程式設計開發人員分享的特殊解決方案，但尚未經過檢驗，還有就是原始模式最初非常簡陋，僅僅隻是一個簡單描述。

一個優秀的設計模式應該有哪些特征呢？

• 解決特殊問題

模式不應該隻是擷取原則或政策，它們需要擷取解決方案。這是作為一種優秀模式不可或缺的要素。

• 沒有顯而易見的解決方案

解決問題的技術基本來自衆所周知的基本原則。好的設計模式會間接的提高解決方案--這被認為是解決與設計相關的最具有挑戰性問題的必要方法。

• 描述業經驗證的概念

設計模式需要證明它們的作用和描述的一緻，并且沒有證明這一點，就不能考慮該設計。

• 描述一種關系

在某些情況下，看起來可能是一種模式描述了一種類型的子產品。盡管一種實作看起來也是這樣，但對模式的正式表述必須能夠更深入地了解它與代碼關系的系統結構和機制。

我們會想當然的認為一種不符合設計準則的原始模式是不值得學習的，然而并不是如此。很多原始模式也是非常有用的，也是可以解決不少問題的，隻是缺少驗證而已。在程式設計過程中，我們需要發揮自己的決斷力，優雅的選擇合适的模式解決問題。

成為有效模式的其中一個附加要求是，它們展示一些反複出現的現象。這通常被限定在至少三個領域内，被稱為三法則：

• 适合性
• 實用性
• 适用性

3.設計模式的結構

上面介紹了一個優秀的設計模式需要滿足的要求，那麼怎麼才能完成一個設計模式的編寫呢？傳統上，一種設計模式最初是以一種規則的形式呈現的，該規則建立下面這樣的關系：

• 上下文
• 上下文裡産生的原件系統
• 解決原件在上下文中自身問題的配置

下面是一種設計模式應該包括的内容：

• 模式名稱
• 描述
• 上下文大綱：模式的使用場景
• 問題陳述
• 解決方案
• 設計
• 實作
• 插圖
• 示例
• 輔助條件
• 關系：與其他模式的關系
• 已知的用法
• 讨論：對該模式優勢的想法

設計模式在規劃和設計階段可能要花費大量的初始成本，但這會對我們的後續開發工作帶來很大的便利，前期投入是非常值得的。但不要為了編寫新模式而編寫，要多選用現有的已經驗證過的優秀設計模式，也可以在現有模式上進行二次開發，滿足自己的需求。

4.編寫設計模式

編寫優秀的設計模式是一項具有挑戰性的任務。很多時候當我們認為某段程式正在使用某種模式時，或許它隻是偶然性的像一種模式而已，我們會發現我們隻是在檢視遵循好的原則和設計實踐的代碼，而這些原則和設計實踐可能偶然會與模式的規則發生重疊。沒有互動和明确規則的解決方案就不是模式。

在進行編寫設計模式之時，下面一些要點是應該時刻牢記的：

• 模式的實用性有多少？
• 牢記最佳實踐
• 設計模式對于使用者來說是透明的
• 要牢記獨創性在模式設計中不是重點
• 模式需要一批有說服力的示例

編寫模式是主要在建立通用、具體及有用的設計方面尋找一種平衡，要努力確定所編寫的模式能夠覆寫最廣泛的應用領域。

5.反模式

模式代表着最佳實踐，那麼反模式就是一種糟糕的實踐，是我們需要極力避免的。

反模式是：

• 描述一種針對某個特定問題的不良解決方案，該方案會導緻糟糕情況發生；
• 描述如何擺脫前述的糟糕情況以及如何創造好的解決方案。

按照優秀的設計模式開發項目，可以使程式簡潔、優雅、易維護，而反模式會為我們帶來有些問題，在日常開發過程中要避免使用反模式。JavaScript中的一些反模式示例如下：

• 在全局上下文中定義大量的變量污染全局命名空間
• 向setTimeout或setInterval傳遞字元串而不是函數，觸發eval()調用
• 修改Object類的原型
• ……

6.設計模式分類

常見的設計模式有很多，它們雖然都是為了給特定的問題提供解決方案，但依然可以從它們的異同點出發，把它們歸類。大緻為：

• 建立型設計模式

建立型設計模式專注于處理對象建立機制，以适合給定情況的方式來建立對象。建立對象的基本方法可能導緻項目複雜性增加，而這些模式旨在通過控制建立過程來解決這種問題。

包括：Constructor（構造器）、Factory（工廠）、Abstract（抽象）、Prototype（原型）、Singleton（單例）和Builder（生成器）等。

• 結構型設計模式

結構型模式與對象組合有關，通常可以用于找出不同對象之間建立關系的簡單方式。其有助于確定在系統某一部分發生變化時，系統的整個結構不需要同時改變，對于不便因某一特定目的而改變的部分，其也能幫它們完成重組。

包括：Decorator（裝飾者）、Facade（外觀）、Flyweight（享元）、Adapter（擴充卡）、和Proxy（代理）等。

• 行為型設計模式

行為模式專注于改善或簡化系統中不同對象之間的通信。

包括：Iterator（疊代器）、Mediator（中介者）、Observer（觀察着）和Vistior（通路者）等。

本文大緻介紹了設計模式的概念、用途、意義及規則等知識點，并未對具體的設計模式進行詳盡的描述，隻是為了給大家勾勒出設計模式的大緻輪廓，後續的文章會詳細探讨這些設計模式的應用場景和使用方式。

資料冰冷的，但我們要讓資料溫暖起來，改變我們的生活！