GUI程序交互設計模式的探索

本文以C#Winform程序為例將題主前段時間做小型建模計算軟體時關於交互設計模型的想法及實現流程進行表述~

該設計模式下軟體與用戶交互只有「一個輸入介面」和「一個」輸出介面，UI元素少的令人髮指~

（一）先說下這個背景軟體關於交互方面的功能需求

最近題主在學習CLR via C# 一書，這是Jeffrey Richter的經典著作，在多線程部分作者有過關於多核編程對UI元素影響的一段討論，限於篇幅，謹摘述如下：「多核革命使我們能夠消除菜單項這樣的UI元素，進而使軟體變得更簡單好用」。這意味著我們可能開發出這樣界面的軟體~

在上面的界面上，UI元素少的「令人髮指」，這怎麼說是對用戶友好好用呢？用戶面臨的選項只有兩個：命令輸入框和右側的輸入提示，用戶只需要了解命令字元及所代表的含義即可簡單有效又不失功能飽滿的使用軟體。這是初看起來用戶交互「不友善」的，稍微了解後就是非常友善的~

基於上述背景，題主想開發的小型建模計算軟體對於交互的需求是：軟體根據用戶輸入的命令字元來進行建模或計算操作，而在這個過程中，命令框右側會有輸入提示，提示用戶進行當前參數輸入。即軟體對外只有「一個」輸入介面和「一個」輸出介面。

題主比較迷戀大師的那段論述，在小型軟體不需要多線程編程的假設下，怎樣才能達到上述令人髮指（對於強迫症用戶可能真的想罵人~）的效果？那就探索設計模式吧。

（二）美兔欣賞

這個圖很美，如果看多次會發現兔子越來越美~

tip：①看完帖子再回頭看美兔效果更佳~；

②被觀察者真的是一隻美兔~。

（三）看兔須知

在以下內容中，題主為表述方便用了一些可能令人不知所云的詞，現聲明如下：

①被觀察者----主窗體類對象

②觀察者----元（單位）功能實現類對象

③觀察者的喚醒函數----IsCallThis成員函數

④觀察者的功能實現函數----DrawElement成員函數

（三）「令人髮指」設計模式

// 3.1********************************************************************************

主窗體屬於被觀察者，各個命令對應的功能實現類屬於觀察者，當前主窗體存有觀察者的列表（容器），當用戶輸入一條命令後，主窗體將遍歷觀察者列表，通過調用觀察者的喚醒函數將命令發送給所有觀察者，通過返回結果進行進一步處理。

// 3.2***********************************************************************************

觀察者通過接收到的命令來判斷是否被喚醒。如果被喚醒，返回true，並將自己需要的參數列表通過委託調用發送給被觀察者（設置被觀察者當前參數列表），同時被觀察者維護當前命令框右側的輸入提示，以便與用戶進行友善的交互~

// 3.3************************************************************************************

用戶根據輸入提示進行一次次輸入，同時被觀察者對輸入的內容進行判斷，如果是參數列表中當前參數的類型，則對參數賦值並維護m_bSeted欄位，返回true；同時調用函數維護命令框右側輸入提示~，以便用戶根據提示進行下一次輸入。

// 3.4**********************************************************************************

在每一次有效輸入後通過檢查參數列表中參數的m_bSeted欄位判斷是否所有參數都已設置，如果都設置了，被觀察者就調用當前有效觀察者的成員函數來實現當前功能並維護輸入提示；否則等待用戶根據命令框右側輸入提示進行輸入直到所有參數都被設置。

當所有參數都設置並調用觀察者功能實現函數實現功能後，被觀察者初始化觀察者列表（容器）、當前有效觀察者和當前參數列表等，以便用戶進行下一次命令輸入，進行下一次功能實現。

最後得到用戶需要的最終結果。

（四）美圖欣賞

（五）

最主要的是對OOP編程語言特點有自己的理解，設計模式都是人開發出來的~；

如果覺得贊就勇敢的點贊吧...雙擊666；

如發現錯誤歡迎指正，有觀點歡迎討論~帖子評論或郵箱watch@163.com；

版權歸題主所有，轉發及引用需徵得題主同意。