認識設計模式

Aaron發表於2020-11-09

最近在學習JavaScript設計模式,對於剛剛起步的小白來說,對有些東西還是很模糊的,所以整理成書面的形式,以免以後忘記,可以反覆的看一下。

什麼是設計模式?

模式是一種可複用的解決方案,可用於解決專案開發設計中遇到的常見問題,比較我們在編寫JavaScript應用程式的例項中。我們定義一個模板,這個模板可以對應多種情況,設計模式也是如此。但是, 你不能像使用現成的函式或程式庫那樣, 拿來某個模式就將其套用到自己的程式中。 模式並不是一段特定的程式碼, 而是用於解決特定問題的一般性概念。

大部分模式都有正規的描述方式, 以便在不同情況下使用。 模式的描述通常會包括以下部分:

  • 簡單描述問題和解決方案。
  • 將進一步解釋問題並說明模式會如何提供解決方案。
  • 展示模式的每個部分和它們之間的關係。
  • 在不同語言中的實現提供流行程式語言的程式碼, 讓讀者更好地理解模式背後的思想。

部分模式介紹中還列出其他的一些實用細節,例如模式的適用性、實現步驟以及與其他模式的關係。

設計模式類別

設計模式以型別劃分主要分為三大型別,創造型設計模式、結構型設計模式、行為設計模式,三種型別設計模式中又包含了更多的是設計模式。

一、創造型設計模式

建立型設計模式是一類處理物件建立的設計模式,通過某種方式控制物件的建立來避免基本物件建立時導致設計上的問題或增加設計上的複雜度。

創造模式包括:

  1. 簡單工廠 - 定義一個物件的工廠介面,將產品物件的實際建立工作推遲到具體子工廠類當中
  2. 工廠方法 - 基於介面資料或事件生成幾個派生類的一個例項
  3. 抽象工廠 - 建立若干系列的一個例項,無需詳述具體的類的作用
  4. 原型 - 用於複製或可克隆完成初始化的例項
  5. 單例 - 一個類在全域性只有唯一的一個例項
  6. 生成器 - 表示中分離物件構建,使用相同的建立程式碼生成不同型別和形式的物件

二、結構型設計模式

結構型模式與物件組合有關,通常可以使用者找出在不同物件之間建立關係的簡單方法。這種模式有助於確保在程式某一部分發生變化時,系統的整個結構無需同時改變,同時對於不適合因某一特定目的而改變的系統部分,這種模式也能夠幫助它們完成重組。

創造模式包括:

  1. 裝飾者 - 向物件動態新增備選處理方法
  2. 外觀 - 隱藏整個子系統複雜性的唯一一個類
  3. 享元 - 一個用於實現包含在別處資訊的高效共享的例項,在有限的記憶體容量中載入更多物件
  4. 介面卡 - 匹配不同類的介面,因此類可以在不相容介面的情況下共同工作
  5. 代理 - 佔位符物件代表真正的物件,提供物件的替代品或其佔位符,代理控制著對於原物件的訪問,並允許在將請求提交給物件前後進行一些處理
  6. 橋接模式 - 可將一個大類或一系列緊密相關的類拆分為抽象和實現兩個獨立的層次結構
  7. 組合模式 - 將物件組合成樹狀結構,並且能像使用獨立物件一樣使用它們

三、行為設計模式

行為模式專注於改善或者簡化系統中不同物件之間的通訊。

行為模式包括:

  1. 迭代器 - 順序訪問一個集合中的元素,無需瞭解該集合的內部原理
  2. 中介者 - 在類之間定義簡化的通訊,以防止一組類顯示引用彼此,迫使他們通過一箇中介者物件進行合作
  3. 觀察者 - 向多個類通知改變的方式,以確保類之間的一致性
  4. 訪問者 - 將演算法語氣作用隔離開
  5. 責任鏈 - 沿著處理者鏈進行傳送,收到請求後,每個處理者均客隊請求進行處理,或將其傳遞給鏈上的下個處理者
  6. 命令模式 - 將請求轉換成一個包含於請求相關的所有資訊的獨立物件,根據不同的請求方法,引數化,延遲請求執行或將請求執行放入佇列中,且能實現可撤銷操作
  7. 備忘錄 - 再不暴露物件實現細節的情況下儲存和恢復物件之前的狀態
  8. 狀態模式 - 再一個物件的內部狀態變化是改變其行為,使其看上去就像改變了自身的所屬類一樣
  9. 策略模式 - 定義一系演算法,並將每一種演算法分別放入獨立的類中,以使演算法的物件能夠相互替換
  10. 模板方法 - 在超類中定義一個演算法的框架,允許子類在不修改結構的情況下重寫演算法的特定步驟


超類:被繼承的類一般稱為“超類”,也有叫做父類。是繼承中非常重要的概念,它和子類一起形象地描述了繼承的層次關係。超類設計的好與不好,首先看其內部重用率的高低,內部重用率高,必然外部重用率也高。

設計模式有什麼好處

既然學習設計模式,當然也會對我們的工作,帶來很多好處,否則設計模式存在的價值也就不復存在了。設計模式不光帶給我們的並不只是良好的編碼規範,其中最重要的可能是思想。

升值加薪

幾乎所有關於程式設計的工作面試和考核中都會有關於模式的問題。瞭解這些知識能夠幫助你發現更廣泛的工作機會, 或者實現升職加薪的工作目標。

增強程式碼質量

模式能讓你對已有的解決方案進行自定義, 而不用完全自行開發。 程式碼中的錯誤將更少, 因為你使用的是經過證明的標準解決方案, 它考慮了所有隱藏的問題。

利於團隊協作

設計模式定義了一種讓你和團隊成員能夠更高效溝通的通用語言。你只需將模式的名稱告訴給程式設計師,而不需要長篇累牘地解釋自己那絕妙的設計思想以及其中各個類的作用。 不費吹灰之力就能搞定同事之間的溝通。你只需說“哦,這裡用單例就可以了”,所有人都會理解這條建議背後的想法。只要知曉模式及其名稱,你就無需解釋什麼是單例。

更快的解決問題

設計模式是針對軟體設計中常見問題的工具箱,其中的工具就是各種經過實踐驗證的解決方案。 即使你從未遇到過這些問題,瞭解模式仍然非常有用,因為它能指導你如何使用物件導向的設計原則來解決各種問題。

反模式

反模式是軟體開發中被認為是壞程式設計實踐的某些模式。用來解決共性問題從而帶來得不良的解決方案。與設計模式不同的是,設計模式是解決常見問題的常用方法,這些常見問題已經正式化,通常被認為是一種良好的開發實踐,而反模式則是相反的,是不可取的。

有人認為反模式是由於將通常使用的設計模式用在了錯誤的地方,也有人認為反模式只是一種壞習慣。簡單的來說,反模式是指在對經常面對的問題經常使用的低效,不良,或者有待優化的設計模式/方法。甚至,反模式也可以是一種錯誤的開發思想/理念。

反模式的流行背後都存在很有說服力的原因,但反模式對可維護性和軟體的長期發展有著更為嚴重的影響。 按照技術債務的說法,每次選擇捷徑都會產生隱含的代價,而這些代價在將來的某一時刻總要償還。 那些推遲的重構不僅會影響下一次變更,而且會像經濟債務一樣持續地疊加利息。

總結

本文主要對設計模式做了一些簡單的認識和了解,接下來的一段時間筆者會不定時更新,上述所說的23種設計模式。接下來的時間我們就一起學習設計模式吧。

在學習過程中不要太糾結於程式碼,學會並理解其中的思想即可,熟練掌握並能運用其種思想在實際開發的專案中,你會發現自己成長了很大一截。

相關文章