C16 View的設計(2)──事件與處理

畫面在顯示之後就等待使用者的輸入與操作。所有程式語言工具對於畫面操作事件都有詳細的規畫與定義，所以大家對Listener介面的使用都很熟悉。這裡想要討論的是Listener的實作與事件對應處理邏輯的關係。

由於操作事件會跟隨著畫面作反應，所以把Listener的實作放在畫面呈現的類別裡是直覺的設計想法。我們發現有時同樣的事件與處理大量地重覆出現在很多畫面（例如系統規定Enter鍵是執行功能的熱鍵），在這樣的情形下相信所有的人會把Listener拉出到一個專門的Class來處理同樣的事件。

現在在這裡最常遇到的問題，是在拉出Listener後仍然把事件發生的對應處理寫在Listener裡面，造成難以切割的密合狀態。這時只要事件與處理邏輯之間的對應關係有所改變，都必須搬動整段程式碼才能達成；就算把這些處理提出到獨立的方法已經有做抽取動作，但也不算是正解。因為，無論如何都會動到程式碼。

如果認真“回憶”的話，我們在需求階段製作的Activity Diagram有分User與System的Swimlane，從User指向System的線條就是event，進去後系統的連鎖Activity正是系統要對應處理邏輯。我們要注意的是，反應由一堆Activity依序組成，每個Activity對應到一個ViewActivity物件的話，管理執行順序的工作交由一個ViewFlow物件處理，Activity的處理內容再交由View Service處理。

右上角的藍色框就是對應每一個event所應該設計的反應機制，當需要再往後執行功能邏輯時，會再往後面的層次傳遞。