軟體設計須面對現實

最近看到有人領域模型中的客戶類別如此設計:

customer_design.PNG

這個設計觀點是將個人戶與公司戶都看成客戶,因且可以把公司戶與個人戶的都有的共通屬性放到客戶類別上,然後把個別所特有的差異化屬性放到衍生類別個人與公司上。表面上,這似乎是Party〔Fowler96〕樣式的應用,然而仔細推究其設計內容,卻會發現這個設計會使系統增加沒有必要的複雜度(Unnecessary Complex)。

因為個人戶與公司戶其實有很大的差異性,衍生類別的屬性很多,也有複雜的處理邏輯,就算我們採用的永續機制框架-Hibernate可以處理類別的繼承,但繼承卻讓我們的類別之間相互牽連,卻只是為了讓公司與個人的屬性不要重覆出現而要花費如此的成本似乎太奢侈了。

其實這個設計最大的問題是只從結構面的角度來設計類別,只考慮抽取共通屬性,卻缺少了行為面的封裝,這是營養不良的領域模型,設計的本質還是採用程序導向的基本思維,造成問題的主因是設計者並未針對實際發生的問題層面來設計,而是以預期的技術層面來考量,也就是說,樣式的錯誤引用把設計問題變複雜了。

為什麼說是樣式的錯誤引用呢?Martin Fowler(1996)曾提過,Party〔Fowler96〕樣式有兩種使用場合:

  1. 在領域模型中看到人與組織具有共同的行為,或~
  2. 不需要區分人與組織,在這種狀況下,可以不提供衍生類別。

由上可知,這個設計並不適用Party[Fowler96]樣式或使用這個樣式的時機並未來到,可以預期的是,少了行為的封裝,實作大致會變成像這樣:

Customer cust = customerManagementService.getCustomer(id);

if (cust instanceof Person.class) {
Person p = (Person) cust;
// process person customer …
} else if (cust instanceof Company.class) {
Company c = (Company) cust;
// process company customer …
}

可想而知,系統設計的複雜度會從此開始衍生下去,這將是我們所不願發生的事情,我的建議是把公司與個人的is-a關係拿掉,因為目前對於一般交易而言,客戶並不需要區分他是個人或是公司,如果需要知道客戶的細節資料時,我們只要提供一個根據客戶編號查詢個人或公司資訊的操作界面,然後在領域模型中將個人或是公司的類別須關聯至客戶類別,這樣我們就可以利用查詢條件的方式就可以找出關聯此客戶的個人或是公司,就可以透過此界面取得此客戶的詳細資料。

如此設計就可以變得更單純些,等到我們需要區分出不同的客戶的共通行為再運用角色塑模(Dealing with Roles)來增加設計的彈性,這就是用面對問題的方式來設計,而不是以技術實作的觀點來設計,因為後者常常會讓我們離遠使用者需求。

在與《類別設計演化論》相關主題的討論過程中,曾針對網友GameBoy所說的「運用 “is a” 和 “has a” 要能洞察 Problem domain(初學的人容易用 real world 直觀的認知來 model,這有點危險),甚至在某些場合併用更能達到 Model 中微妙的動態平衡發揮軟體的軟性」回應:

一味地求虛其實更危險,過度設計的結果是頑空!

實務上常碰到這種人,脫離業務需求,只鑽進沒有必要的設計。

is a 或 has a 並不重要,那只是手段而已。重要的是"面對現實",也就是思考這樣設計究竟要解決什麼問題。因此,用 real world 的直觀來 modeling 沒有什麼不好。

表面上, GameBoy 與我所說的並沒有太大的差異,但我卻不認為「用 real world 直觀的認知來 model,這有點危險」。因為,如果我們不能用 real world 的語言與別人溝通的話,就不可能站在需求的觀點來看事情,我們常常看見在開發過程中,開發人員往往以為只有他們才能了解真正的需求是什麼而造成溝通上的障礙,亦即:

誠如Robert C. Martin在《敏捷軟體開發》一書中提到過的:”程式常常會誘使你遠離樣式或原則”。同樣地,在設計過程中,不適當的設計樣式也常會誘使你遠離真正地業務需求.

樣式學得愈多的人,愈容易發生這種毛病。因此,更需要自我提醒. 不要用技術眼光來看業務需求, 因為那是一種以徧概全的徧見,後面必將自惡果。

所以,站在問題概念的層次上分析問題,而不是站在技術實現的層次上。從概念層次上進行分析,也就意味著要求你從領域專家的角度來看待程式是如何表示現實世界中的概念,然後針對能夠滿足現實世界觀介面設計()。

總之,面對現實才能發現問題的本質,因此設計必須要面對現實。尤其應該要認清不是不能用直觀的方式去看真實世界,而卻是往往我們用錯誤的實作方式而把設計變複雜,尤其是在應用某些樣式之前,必須謹慎,不要讓樣式的錯誤引用讓問題複雜化

Please follow and like us:
分類: 分析設計建模, 設計原則, 軟體開發。這篇內容的永久連結

在〈軟體設計須面對現實〉中有 10 則留言

  1. 自動引用通知: 同人的生活派對 » 探討「用 real world 的直觀來認知 model」

  2. 自動引用通知: 同人的生活派對 » 物件導向繼承與程式碼的重用

  3. 自動引用通知: 同人的生活派對 » 改變軟體開發現況的藝術

  4. 自動引用通知: 同人的生活派對 » 好的設計源自於紀律

  5. 自動引用通知: 同人的生活派對 » 永續物件查詢之設計(其二)

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *