2007年12月20日 星期四

I04 設計常見問題(2)──動作責任定義錯誤

在系統裡兩個物件之間的互動動作,有的時候並不能很明顯地判知該動作要由哪一個Class提供動作方法;不管是客戶提供的需求模糊或是設計者的觀念不佳,都有可能使得動作的責任定義在錯誤的一邊,造成物件的層次被打亂而難以應付需求的改變。

比如說人與車的關係,人可以駕駛車輛,所以有Person.drive(Car)的方法,在裡面再執行Car.move()讓車去計算移動的內容。如果設計的人一時不察,把車子移動的計算寫在drive()裡再直接設定Car的相關資訊的話,雖然呼叫Person.drive(Car)這個功能同樣可運作,但是往後把Car移到其他的系統時就會發現Car根本不會move()。

動作責任的錯置在功能測試上很難測試到,即使是Unit Test裡如果測試程式由設計者寫的話,那麼他將會用自己的定義來作Unit Test而沒測到。問題將會直到某個情境下,Car被獨立出來後才會被發現,但是到那時錯誤的drive()方法已經不知散落在多少地方而難以修正。

動作的責任定義錯誤或是內容遺漏都是負責設計的人在依劇本切割時,必須戰戰競競地時時妥善加以定義。唯有所有Class都僅守本分才能讓系統更有彈性去改變。

沒有留言:

張貼留言