學習設計模式的感想 – what benefits I get after studying design pattern

接觸設計模式的時間說長不長說短不短,但自從接觸了之後,才發現不管網路或者開發者社群,時不時都會有人提出如何學習設計模式的疑問。對於只是聽聞設計模式這個名稱,並被灌輸這個很重要,必須去學的想法的人,設計模式可能就像神祕學一般難易入門。

其實設計模式沒有這麼神奇與強大,只要累積一定的程式開發經驗之後,設計模式的想法基礎自然會逐漸被你聽聞或者吸收 (頓悟)。所謂的學習設計模式,只不過是強行頓悟的一個過程,像是打坐或冥想一般。 這篇文章是我接觸設計模式後的想法彙整,且提到了些關於學習過程的想法,希望可以幫到想接觸的人。

何謂設計模式

設計模式,一開始是為了彌補物件導向程式設計的一些缺點所被提出的,關注在如何規劃整套程式系統的架構。在我的想法中,它奠基於物件導向程式設計以及針對物件導向被提出來的許多設計原則,由眾人的經驗歸納出來的一套方案,用來處理一個或數個常見的需求。 直接用名稱來說文解字:

  • 設計 - 形容一個具有良好特性的解決方案,使得開發出來的程式碼容易被沿用與維護等。如何形成一個良好的程式設計架構,可以參考許多被提出來的設計原則,如SOILD
  • 模式 - 被歸納出來的方案,可以被重複應用在許多場合,解決相似的需求。

曾經被提出來的設計模式可說是過去開發者的經驗,但是每個開發者都可以歸納整理出自己的設計模式,作為提升自己長期程式開發的一大利器。

物件導向中常見的幾個設計原則 - Some Principle of Object Oriented Design 

為何要學設計模式

一般提到學習設計模式,不外乎是指一開始由 “Gang of Four” 四人幫所提出來的 23 種設計模式,或者以這為基礎所衍伸出來的不同書籍。 學習設計模式有幾個優勢:

  • 物件導向程式設計有著物件化、讓物件之間的獨立的特色,因此透過良好的設計,被設計出來的物件可以被重複使用在數個專案之中,大幅提升開發效率。
  • 對開發者個人而言,良好的設計代表容易增減功能容易維護容易重複使用程式碼。
  • 對團隊合作而言,良好的設計可以明確切割開發工作,更容易溝通與分工。物件的專一性,也間接降低開發者互相干擾的可能性。

但是學習設計模式的初期,或者過度崇拜已知的設計模式,可能會出現幾個不良情況:

  • 過度依賴設計模式,可能造成過度設計,準備了過於龐大但不被充分使用的系統設計。
  • 選擇了不適合的設計模式,卻因為相信設計模式的好處而硬是吃下相關的設計開發成本。

學習設計模式,最原始的目的應該是吸收前人的經驗,認識更多使用與設計物件的方法,以及如何更好的依循設計原則來思考,提升自己開發成品的可維護性、可複用性。 設計模式不是規範,可以被捨棄也可以被創新,依照使用的程式語言與引擎環境不同,能夠具有良好特性且符合需求的設計都可被沿用與推廣。

如何學習設計模式

雖然接觸設計模式的時間不長,但我覺得學習設計模式比起熟捻各種模式,更重要的應該是它背後的想法與各個設計原則的來由。 如果要學習設計模式,我認為有幾個環節:

  • 接觸設計模式的管道主要應該就看書、閱讀資料,但不需要自我要求去閱讀 Gang of Four 的原著或者厚厚的外文書。
  • 自行實作專案的經驗很重要。如果接觸過設計模式之前有試著開發出成品,學習設計模式時便可以檢視過去自己使用物件導向的想法有何不妥;接觸過設計模式後更要繼續嘗試開發,不只可以增加理解,或許也有機會體驗過度設計,在未來避免重搗覆轍。
  • 再看幾本書,或多多與人討論,抑或上網尋找他人經驗,反覆體會同一個模式在不同人手中出現的變化。
  • 定期檢視自己的專案,不斷更新想法。

先學物件導向 vs 先學設計模式

  • 物件導向設計模式有上下、依附的關係,但沒有先學後學的差別,兩者是需要反覆理解和相互進步的題組。你可以先學習物件導向,嘗試物件導向開發後,再接觸設計模式來理解自己的做法之優劣;也可以從設計模式開始,理解物件導向的優勢以及各種設計方案,再一一理解每個模式中物件導向的原理。
  • 在我的想法中,頂多是在學習設計模式前,對幾個物件導向的名詞與關鍵字有所理解,會更加容易去閱讀。

學習物件可能需要的基礎 (關於物件導向)

  • 物件的概念
  • 繼承關係,private、protected、public 的差別
  • 定義與實現的差別,關於 abstract、sealed、virtual、override 這幾個關鍵字
  • 成員變數與方法,static 與 non-static 的差別