C20 理論串接實作的瓶頸(5)──Controller≠Component

Controller是系統的靈魂，意即是最重要的部分，但是在許多介紹OOAD技術的網頁裡，Controller就直接被定義成一個Component。這樣的作法，讓我頭痛地摸索很長的一陣子都找不到出口。直到參考了幾篇提到Business Logic與Function Logic應分開設計的網頁後，才終於明白應該要有的理想層次。

先以一個例子來說，我們的系統需要在幾種不同的印表機上列印結果，我們的系統有一套產生列印內容的處理，另外要有驅動印表機的機制。在最初的需求裡只支援一款印表機，所以當時的設計定義一個Interface，再把列印內容的處理與驅動印表機機制寫成直接使用類別（相當於視作一個Component）。

後來因其他專案的需求，必須支援其他兩款印表機。最快的作法就是把原來的類別再複製一組，再修改差異的地方，但是這樣雖然快卻會在系統裡出現數組幾乎相同的程式碼，除了造成維護的負擔也顯示出設計上的問題──幾乎沒有設計而只有實作。

後來還是決議把處理內容的邏輯與印表機控制拆開，在中間插入一個控制印表機用的Interface；這樣就成為三組印表機功能實作對應三款印表機，但是內容處理的部分就只要一組。處理內容屬於Business Logic必須在架構設計時處理，印表機功能屬於Function Logic（因為每種印表機的控制都有差異）是Component細部設計的範圍。這樣的作法才完全符合我的架構設計理念。

省卻設計的層次雖然能夠節省初次開發的時間，但也僅只於此一利，之後的任何結構上的需求變更都將會凸顯其害。