2007年8月29日 星期三

D18 令人感到麻煩的設計(3)──吸收改變的避震器


上面這張圖的狀況是專案物件會廣泛地使用一個底層API。一開始我們很直覺地使用左圖裡的方式直接呼叫BasicAPI的方法,而且沒有遇到什麼問題;後來我們發現有些連續呼叫數個BasicAPI的方法在專案裡很常發生,需要抽出另外成為固定可用的API,於是我們建立了一個BasicAPIExt1,在遇到需要呼叫特定連續方法時使用新的BasicAPIExt1,其他情況則直接呼叫BasicAPI。

中間的圖我們可以看出,專案物件有些呼叫BasicAPI,有些則呼叫BasicAPIExt1,不僅層次的使用比較雜亂,每個專案物件有使用關聯的物件也變多了。設計該是具有層次與抽出共用部分簡化關係的,所以會用右圖的設計,讓BasicAPIExt1繼承BasicAPI來達到這些目的;而且未來BasicAPI的某些改變只會影響到BasicAPIExt1而不會影響到專案物件。

這個範例應用的範圍不只是API,應該包括專案所有使用(static method)或繼承關係的設計範圍。如果能夠費心把專案與元件之間的使用關係都加上一個類似避震器用途的類別(即使只是沿用也要加)的話,將會更輕易應付突然發生的改變。

沒有留言:

張貼留言