2012年10月19日

白話 Design Pattern (十二) Template Method Pattern

Template Method Pattern應用了OO最重要的特性之一『繼承』,來達到封裝演算法、程式reuse的目的.對我而言,它算是最容易理解的模式,甚至在沒聽過什麼是Design Pattern前,就已經自然而然的開始使用了.

假設在一個學校單位的資訊系統,其中有幾個程式片段:

成績判斷
if 身分=大學生
  if 成績 >= 60 
    IsPass = true
  else
     IsPass = false
else身分= 研究生
  if 成績 >= 70 
     IsPass = true
 else
     IsPass = true

選課限制
if 身分=大學生
  max學分 = 22
else身分= 研究生
 max學分 = 12

繳費
if 身分=大學生
  學費 = 20000
else身分= 研究生
  學費 = 1000*學分

這種情形應該很常見,看起來也沒什麼不合理.那會有甚麼問題?

一、擴充不易
如果今天學校要招收博士班學生了,那麼相關的片段可能又都要加上身分=博士班學生的判斷,往後招收夜間部、旁聽生...每次都要增加新的判斷式.

二、邏輯分散
同上,也因為程式片段分散多處,增加或修改的時候一定不能有漏,否則可能出現無法預期的狀況...

三、維護不易
假設今天大學生的選課限制要修改,改成大一到大三是22學分,大四則可以25學分,或更複雜的規則.因為各種身分的選課規則都放在一起,一不小心說不定大學生部分改好了,卻動到研究生的規則,而造成其他錯誤.

說到底還是因為以上方法違反了OCP(Open Close Principle),這時候就應該考慮使用適當的Design Pattern來改善.甚至有一種說法,如果系統中同一種判斷(如例子中的『身分』)出現兩次以上,就應該考慮將其重構.(好吧!這是我自己這麼想的)

解決以上的問題,最簡單的做法就是將建立一個學生抽象類別(Abstract Class),然後讓大學生、研究生繼承之,並將以上程式片段改成呼叫學生子物件.


這麼一來,將來要繼續擴充更多種學生,既不需要更動業務規則,也不怕影響原有的其他學生子類別,簡簡單單就符合OCP.

而實際使用中,在這些程式片段之前,會有一個問題-『學生物件如何生成?』這就可以參考前面的簡單工廠或工廠模式.特別提一下,工廠模式本身也是Template Method Pattern的特例.

當然,這個模式享受了使用繼承的好處,但也可能因此帶來其他問題,否則也不會有其他模式的存在了,更何況還有『少用繼承,多用合成』這樣的設計原則,這就在下一章介紹了.


沒有留言:

張貼留言