W11 專案的開發(4)──Use Case的結果與訊息

做每一件事都有成功的結果或是失敗的原因，這同樣是每一個Activity所應考慮的範圍。使用者操作時必須明白操作的結果，因此每一個Activity都應該要有各自的回傳結果，在Use Case結束時顯示相關訊息讓使用者看到。

底層的錯誤要到設計時才會詳細定義，但是在使用者端還是會有明確的狀態可收集。像從密碼輸入器輸入密碼來說，使用者很明顯地可以考慮到沒有接續、無法按鍵、逾時未輸入等等的錯誤，這些都應先收集起來成為message id。

message id最好是每個Activity都擁有自己的編號而不要共用，這樣做的目的是可以在一拿到編號就知道是在哪裡發生的問題；當然，不同的id可以指定顯示相同的名稱，因為使用者只是需要知道有錯而不一定要知道在哪裡錯。密碼輸入器與鍵盤輸入的逾時理應有兩個不同的message id但是在顯示時可以只有＂密碼輸入逾時＂一種敍述。如果二者的message id都相同，要是哪天客戶希望二者顯示的訊息不同時，又會令人跳腳。

軟體的複雜度其實有很多是人為造成的，其中又有很大部分是把多個來源混雜成為一個定義。在系統沒有變動的時候，因為執行的結果全都正確所以這種定義並沒有問題；但若有問題或變更造成的修改落在原來的多個來源得分割為不同的定義時，真的是改的越底層就陣亡越多人。忠實地用一個定義對應一個來源是降低這類風險的最佳作法。

讓每個Activity都只擁有自己的message id就毋需製作追溯表，因為這只是一對多的擁有關係。message id與實際顯示的訊息內容是多對一的關聯，不過在實作時會因為properties的作法而被攤平為一對一。