訊息專家三部曲(一) 概要篇 | Information Expert

2024-08-01
GRASP

資訊專家就是老大。

資訊專家就是老大,圖片來源

情境

“ 在物件導向開發中,至關重要的能力是熟練的為物件分配職責。 ”

― Craig Larman, Applying UML and Patterns 3rd, ch1.2

如果是剛出社會的軟體工程師,相信大家都有看過古老的程式, 裡面有著許多物件,你不知道那些物件,因為那些物件是屬於專業領域的專業術語,然後你想說

「我想要成為一名優秀的員工哼 ! 才區區幾萬行,當學生都不知道讀了多少書,輕輕鬆鬆。」

然後前輩跟你講,這個很複雜喔,你先看,有不會再問我們。

過了兩三天,你的心態開始有些轉變了,你發現了以下幾個問題

  • 這隻企鵝怎麼會飛啊!
  • 這個物件怎麼包山包海啊!
  • 這個專業術語怎麼跟網路上查的好不一樣!

此時前輩的叮嚀「這個很複雜喔,你先看,有不會再問我們」,就像是最後一根救命稻草,你拿著筆電去詢問,詢問結束後,大概會有以下情況 :

  • 前輩劈哩趴拉說了一堆,你也是糊里糊塗的似懂非懂。
  • 講到一半,前輩反問你「考考你那為甚麼這程式碼是這樣寫」。
  • 前輩搖頭說,這就是技術債,沒辦法…

此時你的腦袋是混亂的、心態是崩潰的,開始想著,我是不是不適合當軟體工程師….


訊息專家

職責為一個物件需要做的操作,在 UML 中職責被定義為類元的契約或義務;在編寫程式碼中方法為職責的實作,職責是某個概念的行為,例如 : 狗會『跑』、羊會『叫』、玩家會『抽牌』、骰子會『呈現數字』。

那具體的職責分配該怎麼實作呢? 我需要一套SOP! 此時就是訊息專家的步驟出場的時候了。

訊息專家怎麼實作?

“ 把職責分配給具有完成該職責所需訊息的那個類別。 ”

― Craig Larman. Applying UML and Patterns 3rd, ch17.8

在進行分析與設計時,概念會有其所攜帶的訊息,也就是類別的屬性

行為的完成通常需要這些屬性來進行,因此當一個物件具有某行為 (方法) 需要的所有訊息 (入參),則可以將該職責分配給物件,可以說因為該物件是這個職責的訊息專家,所以將職責由它實現。

而具體的有四步驟

  1. 陳述職責
  2. 概括該職責所需訊息
  3. 列出所需資料的提供者(物件)
  4. 判斷職責的歸屬

透過以上四步驟、再配合用例分析出的物件與職責,基本上對於物件的職責分配有個基礎的理解與手段。

例子的情境

以下是一個簡化版本的訂單總價的計算,以下是用例分析。

用例 : 計算訂單總價

主要參與者 : 顧客

前置條件
顧客已經選擇了一些商品並添加到購物車中
系統中已經有這些商品的價格信息
顧客開始結賬流程

主要流程
1. 計算每件訂單項目的小計(商品單價 * 數量)
2. 將所有小計相加,得出訂單總價
3. 顯示計算出的總價給顧客

後置條件
訂單的總價被正確計算並顯示給顧客

在這個案例中,我們能知道職責是計算訂單總價,並且從主要流程中知道有訂單、訂單項目、商品這幾個物件,知道了訊息專家的四步驟,接下來你會怎麼用程式碼表達呢?


作者心得

雖然在 Applying UML and Patterns 書裡,相較於訊息專家,控制器、創建者是先介紹的,但訊息專家在我心中是在GRASP中最重要的,因此就先介紹了。

信息專家雖然只有四個步驟跟把職責分配給具有完成該職責所需訊息的那個類別這個簡單的敘述,但其實包含了其他很多的設計原則,這在之後的第三篇會進行介紹。

沒想到吧! 一個訊息專家可以寫三篇。


參考資料

也可以看看以下文章