案例情境
世界大軟體公司有一款行銷分析的系統，具備了多功能的分析能力，並且能夠產出各種漂亮的分析圖表。當然，可以想像的到，這個行銷分析的圖表使用了第三方的廠商霹靂軟體公司設計的圖表產生元件。
日前傳出了一個不幸的消息，霹靂軟體公司的總經理掏空公司，導致霹靂軟體公司不幸倒閉，週日在光華商場的門市還舉辦了跳樓大拍賣，造成了瘋狂搶購，還有人漏夜排隊….總之，世界大軟體公司為了日後的廠商支援考量，決定更換圖表輸出元件的提供廠商。結果苦命的RD部門在Google找到了一家叫做犀利士軟體公司，提供了更強大的圖表輸出功能，因此，公司拍版定案決定下一個版本即提供使用犀利士軟體公司圖表元件的分析系統。 如果你是RD部門的小工，你會選擇用什麼樣的方案來進行改版呢？
利害關係考量
在RD的部門會議上，經理John這麼說，「喂，公司高層已經決定要把圖表分析的元件換成犀利士的圖表元件，你們看看有沒有什麼想法。」
詹姆士胖的：「經理大人，我覺得為了堅持我們軟體人的風骨，我們應該全部改寫，把舊有的程式碼全部替換掉。」
瀟灑男阿KEN心想，「哇靠，我明天晚上還要去跟美眉聯誼耶，別瞎搞了，這樣要弄到民國幾年。」於是說道：「啟稟經理，為了遵循偉大的八十二十法則，我們應該把精力花在更有產能的工作上，例如研讀總經理如何成功的傳記，而不是這類沒有產值的工作上，所以我建議我們寫個轉接器把舊有系統跟新元件銜接上即可。」
經理John心想，「這小子很會拍馬屁嘛，看樣子得小心他才行。」表面上則點點頭稱是，「很好，阿Ken的論點擲地有聲，還多方舉證，我們就依照他的建議吧。對了，這個工作就交給詹姆士來進行，阿Ken你去好好研讀一下總經理的自傳，明天晚上的讀書會你要參加，發表一下你的心得吧。」
系統分析
回到正題，詹姆士研究了一下舊有的軟體架構，畫出了下面的類別圖來。
點選上圖可以檢視原始大小
如同上圖所示，客戶端程式使用了 ChartOperation 這個介面來操作圖表元件，而舊有的圖表元件則為實作了 ChartOperation 介面的 PieChartOperation 類別。為了不更動到舊有的客戶端程式，因此詹姆士胖的決定使用轉接器樣式來進行更換的工作，他想了一下，之後畫出了下面這樣的類別圖。
點選上圖可以檢視原始大小
我們來觀察一下上面這張類別圖，NewPieChartOperation 類別就是犀利士公司所販賣的圖表元件中的類別，很明顯的可以看出，它進行繪圖的操作與舊有的操作介面不同，舊有介面的操作為 DrawPieChart ，而犀利士的圖表元件則為 Draw_A_PieChart，如果要直接使用這顆元件的話，勢必要更動到許多既有的程式碼，說實在的，是很吃力不討好的一件事情。
因此，我們折衷的採用了一個 Adapter 類別，Adapter 類別將會實作舊有的 ChartOperation 介面，而舊有的客戶端程式碼仍然只需要面對舊有的介面，程式碼也就不會有太多變動。
可以想像的到的，變動的部分將交由 Adapter 類別來負責，當客戶端呼叫 Adapter 的 DrawPieChart 方法時，它將會去呼叫 NewPieChartOperation 的 Draw_A_PieChart 方法。
結論
經由一個轉接器類別來作為既有程式之間溝通的橋樑，這樣的架構我們稱之為轉接器樣式（Adapter Pattern）。在現實的世界中，當然會面對更複雜的問題，那麼轉接器的程式碼也就相對的會複雜的多，但是都比起直接修改舊有程式碼要來得好。
此外，一旦建立起這樣的轉接器架構之後，日後這顆繪圖元件若是需要再進行更動時，我們只需要調整轉接器類別即可。這樣的理念也符合物件導向設計原則中的封閉開放原則，既有的程式碼封裝起來，易於變動的程式碼與其抽離，盡量做到兩者之間不互相干涉。進而便達到物件導向的易於維護與擴充的優點。
2008/6/26 21:13|
閱讀數 : 320
|
我要推薦
|
|
文章分類:
理論基礎
訂閱