設計模式反映問題的抽象分類

訂閱電子報│RSS訂閱 │手機版

全站文章

iT邦幫忙

iThome Online提供免費電子報，現在就訂，最新IT訊息每日寄達。

iThome 每日新聞報

iThome 產品技術報

加入iThome Online會員，立即使用討論區、Blog等服務。

‧登入 / 登出

‧	12' E政府專刊no.6(46)
‧	12' 個資法專刊No2(45)
‧	12' iTcloud No.2(44)
‧	12' e政府專刊No.5(43)
‧	12' 個資法專刊(42)
‧	11' CIO專刊(41)
‧	11' e教育專刊No.3 (40)
‧	11' e政府專刊No.4 (39)
‧	11'iTcloud專刊(38)
‧	10' e教育專刊No.2 (37)
‧	10'e政府專刊No.3 (36)
‧	09'e政府專刊No.2 (35)
‧	09'e教育專刊(34)
‧	09'e政府專刊(33)
‧	08'企業資安專刊－端點安全防護(32)
‧	08'企業採購情報誌(31)
‧	07'資訊安全技術應用專刊(30)
‧	07' 新世代資料中心專刊(29)
‧	07'企業資安技術應用專刊(28)
‧	企業採購情報誌'06冬季號(27)
‧	企業軟體技術應用專刊(25)
‧	企業資安技術應用專刊(24)

設計模式反映問題的抽象分類

文/林信良 2012-07-04

瞭解設計模式應著重在理解問題本質

林信良
因在網路上經營「良葛格學習筆記」（openhome.cc）而聞名，曾任昇陽教育訓練中心技術顧問、甲骨文教育訓練中心授權講師，目前為自由工作者，從事講師、技術書籍寫作與翻譯，專長為Java 程式開發相關技術教育訓練，研究興趣包括：程式語言、Web 相關開放原始碼框架。閒暇之餘記錄所學，技術文件涵蓋 C/C++、Java、Ruby/Rails、Python、JavaScript 等領域。

在Gof書中寫到，設計模式是在特定情境中，為解決通用設計問題的自定義物件互動說明。許多開發者將焦點放在解決，模式名稱成了解決方案的代名詞，甚至將說明用的具體程式實際當成複製、修改的對象，忽略了設計模式實際上反映語言面對領域需求時的常見問題，這些問題在解決時出現類似的思考流程，而設計模式是將思考流程抽象化後進行分類，每個分類都代表了問題的抽象集合。

瞭解設計模式是鑑古知今
儘管實際面對的程式需求各不相同，然而多數問題存在某些重複的相似性，設計模式是思考問題相似性的過程，將觀察到的相似性從實際問題中抽取出來，討論設計上如何解決抽取出的相似性，以求面對類似的具體問題時，可以有現成的抽象概念可以套用，以降低思考過程的複雜度。

舉例來說，圖形介面開發者在面對使用者版面配置需求時，曾思索物件間如何組合，以提供自由組合版面的彈性，動畫剪輯開發者在面對使用者圖片、影像剪接需求時，曾思索物件間如何組合以提供自由組合影片的彈性，測試框架開發者也曾思索物件間如何組合，以提供自由組合測試案例的彈性。

以上問題的相似性是「自由組合」，解決方案也呈現類似結構與行為，因而抽取出組合（Composite）模式的概念，日後若觀察到問題有自由組合的需求，組合模式就可提供現成抽象概念，免去探索解決方案的複雜過程。

某些程度上，設計模式有點像是管理學原則，許多管理書籍會從過往歷史探索某些公司或機構，從各個角度提出某種關鍵因素，巧妙地與歷史串接，起來論斷公司或機構的興衰成敗，閱讀管理書籍只是瞭解有哪些角度可以切入管理問題，而不是那些角度就是最佳觀點或解決方案。在經營中的公司或機構採用某些管理原則，或避開某些管理方式，也並不保證公司或機構必然興盛，或免於敗亡。

無論是從閱讀文件瞭解設計模式，或是在閱讀程式碼時發覺採用了某些模式，都得先理解需求的情境、問題的核心，也要瞭解文件或程式中出現的設計模式實作，也許僅是可能的解決方案之一，有時同一問題在不同應用程式中採用的模式可能不盡相同，就如同有些管理原則在不同公司體系中可能是相對的矛盾。

閱讀管理書籍，是在瞭解不同公司或機構經營時會有哪些問題，瞭解設計模式，是在瞭解應用程式開發過程中可能會遭遇哪些需求，兩者的共同點，都是如何從過往中抓出問題的核心。

1 / 2 / 3

‧	6/20-6/21 Enterprise Cloud EXPO 企業雲資源應用博覽會與企業雲端論壇
‧	2013 BlackBerry Enterprise Experience Forum-無庸置疑的企業行動化使命
‧	2013 BrainShare Technology Forum Asia Pacific Tour
‧	2013台灣三星飯店與零售解決方案高峰會
‧	2013 Java Developer Day
	更多研討會

▼ ADVERTISEMENT ▼

▲ ADVERTISEMENT ▲