也談物件導向的系統功能設計

         之前在寫我的程式人生的過程中，很多網友都希望我介紹一些編程開發方面的經驗。我之前也說過，雖然我也算電腦專業科班出身，不過很多東西並不是在學校裡從老師那裡學來的，而是在工作中經過失敗後總結出來的。至於總結出來的是不是最好的，最適合的，那就不知道了。我只知道在我目前的系統開發過程中，還是有一定作用的。本文我就想從系統功能設計方面簡要介紹一下自己的一些思路和模式，也希望能夠對大家起到拋磚引玉的作用。如果您有更好的方法，請務必留言賜教。

 1。系統設計目標

        封裝性：高內聚，低耦合

                對模組進行封裝，便於重用，模組變化產生的影響範圍最低。       
         可擴充性：考慮未來擴充的可能                    函數，介面的設計，要考慮未來可能產生的擴充          一致性：包括模組設計的一致性，以及不同系統中同一模組的一致性
                  模組設計的一致性，要求各個模組採用一致的設計思路，簡化設計的複製度，提高可讀性和可維護性。  2。系統設計要點         追求完美，但不鍍金                 要有追求完美的心態，但卻不能鍍金，過猶不及。                 注意80：20原則。爭取用20%的成本實現80%的功能，而避免用大量的時間解決非重點問題或低機率問題。
         換位思考，從使用者角度考慮問題                 特別對於介面的設計，包括圖形和內容的顯示。要以一個使用者的角度來考慮。操作簡單，介面美觀，穩定高效等。
         各盡其責                 理解類和模組的意義，明確每個類和模組的責任和角色。不做不屬於它的工作。一旦出現不應該由本類來完成的工作，那麼意味著你的模組已經存在缺陷。

3。系統架構結構

具體每個部分的作用在以下的各個部分進行介紹。

4。MFC基礎類職責

        MFC基礎類包括應用程式類，主架構類，視圖類和文檔類。         應用程式類負責系統初始化，包括檢查設定檔資訊的有效性，資料庫是否能正確串連，系統是否註冊等前端工作，以確定是否需要啟動系統；
        主架構類負責工具條，狀態條，菜單和浮動表單的管理，並作為整個工程中訊息收發的中轉站；        浮動表單將作為一個容器，以TAB頁的方式整合各個模組的資訊展示和互動視窗，使得整個系統能有有效視窗管理，不至於出現浮動視窗滿天飛的現象。
        視圖類負責響應使用者的滑鼠和鍵盤事件，根據當前的操作狀態將使用者的動作投遞給對應的實體模組管理類進行處理。並將結果在視圖中進行繪製；        對於視圖的作用，要記住一個原則，它只負責資訊的互動，包括接收各種輸入，以及相應的資訊展示，不進行任何與業務相關的處理，所有業務相關的處理，都必須交由各個業務模組的管理類來完成。         文檔類負責記錄各個實體類對象的執行個體。        現在文檔類的功能相對弱化，勉強負責業務模組對象的管理。

5。獨立模組的組成結構

        每個模組大致包括一個管理類，一個資訊視窗類別以及若干實體類。         管理類負責封裝實體類對象與外界的互動，接收視圖類傳遞來的滑鼠鍵盤事件並進行調度；        從抽象層的角度來講，管理類和視圖類有些相似，它是在業務模組中的“視圖類”，負責接收外界對模組的請求，並返回業務模組對外部請求的處理結果。         資訊視窗類別用於以資料或圖形方式向使用者展示實體類對象的資訊，並接收使用者的輸入；         實體類表述具體的模組業務，可以根據需要分解成更多更具體的子模組。         資訊視窗類別和管理類為強關聯關係，資訊視窗類別為管理類的友元類。管理類和資訊視窗類別都作為業務模組的輔助對象，原則上認為它們都是依賴於業務模組類而存在，因此，將兩者作為一個整體。 6。訊息機制        為了降低類之間的耦合度，類之間使用訊息進行資訊傳遞。         發往視圖或者浮動表單的訊息，可以通過主架構類進行轉寄，這樣可避免實體類和視圖類以及浮動表單類的強綁定。        為了避免在業務模組中直接引入當前工程的視圖類等類對象，而導致業務模組和當前工程產生強關聯的現象，所有業務模組的訊息都發往主架構類，然後由主架構類負責轉寄給各個展示視窗，比如視圖、浮動視窗等，它們都是由主架構類進行管理的。         為了支援某些特定的功能，系統增加類似的訊息反射機制，視圖發往具體模組類的滑鼠事件如果該模組無具體的操作和變化，那麼將把該事件通過訊息發送給視圖，以便可以進行預設的功能處理。 7。模組設計        一個模組可以分解為若干個物理類和邏輯類。物理類負責封裝資料和對資料的直接的讀寫和處理方法；邏輯類負責管理和調度物理類。
        物理類之上又可進行抽象，形成基類，充分利用物件導向的方法進行類的設計。         明確各個類的權利和義務，不做不屬於它的工作。這一點可以和公司管理結構相對比來理解。
        類的成員變數和方法，必須明確其屬於公有，保護還是私人。成員變數應該提供方法封裝讀寫操作。        以上基本上是作者多年來摸索出來的一套系統功能設計的模式，在作者一直以來的項目實踐中得到應用。模組的遷移和替換代價都較低。由於所有模組有較好的一致性，新員工也能夠對系統結構在更短的周期內得以掌握。當然，這隻是一孔之見，還請大家多多給予意見。