I05 設計常見問題(3)──邏輯散落多個層次

在D02裡提到Use Case裡的邏輯應被拆分為需求邏輯與動作邏輯。需求邏輯是根據客戶的規格加以規劃應有的動作與順序，動作邏輯則是與需求無關而是以能夠完成指定動作為目的；後者的作法應是固定不動，動作的微調用設定與參數來改變，前者需去適應客戶可能有的改變，再依動作的規格找出適用的元件或專案上的特定方法。

需求邏輯與動作邏輯的分工可以讓重覆使用的元件與專案的客製化差異能同時存在並達到相輔相成的效果，其中的使用界限是非常明確的。但是一般在設計時很有可能發生需求邏輯散落在功能邏輯裡做事的問題。

客戶要在進行列印動作後在畫面顯示一個對話盒告知成功或失敗原因，在我的設計觀念裡訊息的內容與顯示方法都該在需求邏輯裡處理的，不過專案裡如果沒有人去定義層次與該在哪一層做，訊息的部分有時會不小心被寫進印表機的動作程式裡。這便是所維護產品裡的一個實例，而且兩組印表機的不同實作竟然是一組沒處理訊息而另一組有。

在訊息處理寫入印表機動作的那組實作，在不同專案裡想把訊息顯示在畫面欄位，此時必須加一個顯示方法把欄位傳進去才能在裡面顯示。但是這樣一來印表機程式就綁上了顯示的元件，要不然就是重新改寫印表機實作；改寫比較符合設計原則，但是改了以後之前使用訊息處理內建的那些專案要怎麼辦呢？

專案裡時常發生東西改來改去的狀況，而且一改就是一大片，其實那一大片都是自己造成的……。