Design pattern 軟體工程必須面對的設計模式

Home >> Blog >> Design pattern 軟體工程必須面對的設計模式

設計模式

在軟體工程中，設計模式是針對軟體設計中常見問題的通用可重複解決方案，尤其是面對相同產業的SEO優化方案時就可以應用設計模式來處理以節省人力與時間。設計模式不是可以直接轉換為程式碼的完成設計。它是關於如何解決問題的描述或模板，可以在許多不同的情況下使用。

設計模式的使用

設計模式可以通過提供經過測試的、經過驗證的開發範例來加速開發過程。有效的軟體設計需要考慮在實施後期才可能顯現的問題。重用設計模式有助於防止可能導致重大問題的細微問題，並提高熟悉模式的程式設計人員和架構師的程式碼可讀性。

通常，人們只了解如何將某些軟體設計技術應用於某些問題。這些技術很難應用於更廣泛的問題。設計模式提供通用解決方案，以不需要與特定問題相關的細節的格式記錄。

此外，模式允許開發人員使用眾所周知的、易於理解的軟體交互名稱進行通信。常見的設計模式可以隨著時間的推移而改進，使其比臨時設計更健壯。

創造型設計模式

這些設計模式都是關於類實例化的。這種模式可以進一步分為類創建模式和對象創建模式。雖然類創建模式在實例化過程中有效地使用繼承，但對象創建模式有效地使用委託來完成工作。

• 抽象工廠
  創建幾個類族的實例
  
• Builder
  將對象構造與其表示分離
  
• 工廠方法
  創建幾個派生類的實例
  
• 對像池
  通過回收不再使用的對象來避免昂貴的資源獲取和釋放
  
• 原型
  要複製或clone的完全初始化的實例
  
• 單
  例 只能存在一個實例的類
  

結構設計模式

這些設計模式都是關於類和對象的組合。結構類創建模式使用繼承來組合接口。結構對像模式定義了組合對像以獲得新功能的方式。

• 不同類的 適配器匹配接口
  
• Bridge
  將對象的接口與其實現分開
  
• 複合
  簡單和復合對象的樹結構
  
• 裝飾器
  動態地為對象添加職責
  
• Facade
  代表整個子系統的單個類
  
• Flyweight
  用於高效共享的細粒度實例
  
• 私有類數據
  限制訪問器/修改器訪問
  
• 代理
  代表另一個對象的對象
  

行為設計模式

這些設計模式都是關於類的對象通信的。行為模式是那些最特別關注對象之間通信的模式。

• 責任
  鏈 在對象鏈之間傳遞請求的一種方式
  
• Command
  將命令請求封裝為對象
  
• 解釋器
  一種在程序中包含語言元素的方法
  
• 迭代器
  順序訪問集合的元素
  
• 中介者
  定義類之間的簡化通信
  
• Memento
  捕獲並恢復對象的內部狀態
  
• 空對象
  旨在充當對象的默認值
  
• 觀察者
  一種通知多個類變化的方法
  
• 狀態
  當對象的狀態改變時改變其行為
  
• 策略
  將算法封裝在一個類中
  
• 模板方法
  將算法的確切步驟推遲到子類
  
• 訪問者
  為類定義一個新的操作而不做任何改變
  

批評

設計模式的概念在計算機科學領域受到了一些人的批評。

針對錯誤的問題

對模式的需求源於使用抽象能力不足的計算機語言或技術。在理想的因式分解下，一個概念不應該被複製，而只是被引用。但是，如果某些東西被引用而不是複制，那麼標籤和目錄就沒有“模式”。

Peter Norvig 提供了類似的論點。他證明了設計模式一書中的 23 種模式中的 16 種（主要關注 C++）在 Lisp 或 Dylan 中被簡化或消除（通過直接語言支持）。

缺乏正式的基礎

對設計模式的研究過於臨時性，有些人認為這個概念非常需要建立在更正式的基礎上。在 OOPSLA 1999上，四人幫（在他們的全力合作下）接受了一場表演審判，其中他們被“指控”了多項危害計算機科學的罪行。他們被出席審判的“陪審員”中的⅔“定罪”。

導致低效的解決方案

設計模式的想法是試圖標準化已經被接受的最佳實踐。原則上這似乎是有益的，但在實踐中，它經常導致不必要的程式碼重複。使用結構良好的實現而不是“勉強夠好”的設計模式幾乎總是一種更有效的解決方案。

與其他抽像沒有顯著差異

一些作者聲稱設計模式與其他形式的抽像沒有顯著差異，並且沒有必要使用新的術語（從架構社群借來）來描述編程領域的現有現象。模型-視圖-控制器範式被吹捧為“模式”的一個例子，它比“設計模式”的概念早了幾年。一些人進一步認為，設計模式社群的主要貢獻是使用 Alexander 的模式語言作為一種文檔形式。一種在文獻中經常被忽視的做法。