編程規則 – 3 類設計規則（1）

 摘要：類設計原則 編程規範 設計規則 編程指導      參閱：概述
  命名

3 類

    在OOP的開發過程中，類是系統的基礎和關鍵組件，類設計的水平決定了整個系統設計水平，因此我們必須不斷提高類的設計能力，而且它遵守最簡單的往往最重要的原則，一個系統中的實體物件及用於傳輸的資料對象（它們往往也是服務的輸入、輸出對象）的設計更加重要，因此我們必須把資料對象的設計提到一個相當的高度，資料類反映系統的本質，它們是系統中相對穩定的部分，有了良好的穩定的資料類設計，才能得到一個良好設計的系統，因此必須在資料類設計上下大力氣，資料類設計水平反映你對業務領域的認識深度，影響後續的所有設計環節，換句話說沒有良好的資料類設計，就不可能得到一個好的系統。

3.1 軟體系統設計的基本原則

為了更好地進行類設計，首先介紹軟體系統設計的幾個重要原則：

1）面向本質，不要面向表象。

在一個系統中資料、資料結構、實體物件和與行為相關的傳輸對象是業務領域的本質，功能實際上是表象，眾多因素會導致功能需求的差異，而大多數軟體設計人員以功能為導向設計系統，實際上是本末倒置，也是造成目前軟體系統難於發展和維護的重要原因；但一個業務領域中的關鍵業務處理邏輯是相對穩定的，是本質的，是設計要重點考慮的另一部分；設計人員經常將功能與核心商務邏輯混為一談，實際上功能是通過調用一個或幾個核心處理邏輯完成的，功能是千變萬化的，核心商務邏輯是穩定的，他反應行業本質。這匯出另外一個重要的設計原則：

2）分離基礎業務處層與功能處理層

基礎處理模組反映行業的核心處理邏輯，是本質和穩定的，功能處理模組是面向服務的，是易變的，基礎處理模組是功能模組的基礎支撐，功能處理模組反映粗商務邏輯，基礎處理模組反映穩定的細商務邏輯，堅實穩定的基礎處理層是整個系統的基石，兩層的合理劃分，是系統穩定和靈活的基礎。

3）分離資料與邏輯

在一個系統中，資料與邏輯比較而言，資料是易變的（這裡的資料不是前面提到的資料類-資料結構，而是參數），邏輯是相對穩定的，如果兩者混在一起，整個系統就無法安定了和適應變化了，例如列印的位置、顯示的屬性，業務控制參數（費率、利率、業務方式、客戶性質等），如果這些資料些死在程式中，將使系統僵死而失去活性，如何全面完整地將資料從邏輯中剝離出來，剝離出來的資料如何儲存與管理，是設計中的關鍵話題；我們的設計開發平台，在ADM（Applaction Description
Model）中已經為確定類型的參數和不確定類型的參數建立的儲存模型，不確定類型的參數可以使用CO-通用配置參數模型，極特殊的可以繼承Root類自行定義X類參數以滿足具體要求，這樣的資料可以通過參數工廠進行統一的儲存管理，可以通過通用維護介面（或專用維護介面-對於X類參數）進行可視化維護。也就是說平台解決了儲存和管理的問題，但如何正確地分離則是你設計師要認真思考反覆推敲的了。

4）開閉原則

軟體實體（模組，類，方法等）應該對擴充開放，對修改關閉。這即是一個原則也是系統設計的重要目標，就是讓軟體系統即穩定又開放（注意這是一對矛盾），這可以稱為軟體系統設計的總則，前面談的原則也是為它服務的，該原則後面還會介紹，它比較抽象，需要你不斷去體會和實踐，在你未深入理解時，你努力遵守上面的幾個原則，另外在設計過程中努力認識和識別變與不變的東西，並將之科學地分類開，類似資訊隱藏技術，實際上分離變與不變、分離資料與邏輯都是貫徹開閉原則的重要方法，為了是你更好地理解上面的概念，下面給出一些具體指導：

軟體系統中結構化的（如實體類、傳輸類）、反映行業的基礎商務邏輯（如銀行的記賬邏輯、計息邏輯）是穩定的，功能和展示層（如介面、報表等）、技術手段（如通訊協議、加密方法等）是易變的。分解出不變你就獲得系統穩定的基礎，管理易變你就獲得系統靈活性。

在我們的平台體系下已經對介面、報表、通訊、加密等進行和很好的剝離和封裝，在具體系統設計中需要重點解決的就是實體及傳輸類設計，基礎服務層與功能層的分離，業務參數與商務邏輯的分離。

實體類相對比較容易設計，實際上它與資料庫設計緊密相關，在我們的平台體系下他們實質就是一體的，與行為相關的傳輸對象，設計上要多下功夫，首先你必須對整個業務領域的所有功能進行歸類分析，並以此為基礎進行傳輸類的類圖設計，以銀行為例，首先傳輸對象必須有一個共同的基類（它包含各種傳輸類的交集屬性），然後在功能歸類分析的基礎上，對各功能行為屬性進行分析和抽象，發現上千種功能，從行為屬性上可以劃分為如下五大類：

A）客戶資金類業務

B）客戶一般性業務

C）內部資金類業務

D）內部管理類業務

E）查詢類業務

各大類下派生其他子類，如A）可以派生客戶現金類、客戶轉賬類、客戶外匯類等業務；

但基於行為屬性抽象（而不是基於功能）設計的傳輸類的類樹規模將明顯縮小，而且它是面向業務本質的，是相對穩定的。細心的你可能會提出一個問題，我們在設計傳輸類時，首先要對功能進行全面分析，這不是面向功能了嗎？不對！這隻是一個手段，我們最終的目的是實現對行為屬性的抽象，實際上我們無論做什麼都必須（也只能）透過現象看本質，功能是表象，我們必須通過它（分析它）才能得到行為屬性類圖（本質），而且你一定要注意，這屬性類圖並不是擺在那裡，而是需要你的分析、抽象、歸納、推敲，解開重重迷霧，才能得到，這才能體現你的設計能力，也是設計的魅力。強調不要面向功能，不是讓你不分析功能，恰恰相反，你需要認真地、反覆地分析研究它，直到你真正地理解和消化吸收，你才能開始設計，才能做好設計，強調不要面向功能是指導你不要只看錶象，不要照葫蘆畫瓢，就事論事，面向功能設計的系統是脆弱的、拙劣的、無法適應變化的。

  .....待續