一.實現商業對象
封裝了商業規則的類是真正面向對象編程的基礎
這篇文章我們會涉及程序設計的各個方面，并對質疑一些我們寫Delphi程序的慣用方式。這些設計方法背后的基礎概念是封裝：設計一組清楚定義接口（方法）類，由這些方法去操作他們的屬性。這一概念將會貫串整個程序并對數據如何保存和呈現有很大影響。我愿意介紹讀者學習Francis Glassborow's關于C++的文章，盡管語言不同，但是優秀的類設計理念是和語言無關的。
現今大部分Delphi寫的程序都不是面向對象的。只是語言中有對象的模型并使用了原有的或新的類，這并不意味者程序是真正的面向對象。代碼的重用隨著第三方控件被拖到窗口上而結束，窗口和單元之間的相互依賴卻在迅速擴散。（！！?。┤绻麑硪淖兂绦虻幕A（如切換不同
數據庫或從兩層結構變成三層結構）會嚴重受阻或花費昂貴。如果是真正按面向對象的方式寫的程序則會很方便而不是受限制。當然要寫這樣的程序需要理念的提升，而且開始的時候缺乏生產力，大部分開發團隊都不情愿這樣或作考慮。我希望通過這篇文章向大家示范如何能寫出更好的程序。最終使系統更可靠，容易維護，風格一致，靈活，可重用，比用傳統方式寫的程序運行的更好。特別是對大型的程序，代碼清晰并真正面向對象的程序會比傳統方式寫的同樣程序需要更少的維護資源。
面向對象的程序更高的可靠性來自于數據和操作被封裝在明確定義的類中。編譯器通過強大的類型檢查促使代碼中正確的類、方法和屬性，對未來一個改動會影響整個程序的代碼不應讓人有誤解代碼意圖的可能。正確使用類會是類之間的關系是自明的，并且大部分的代碼真正關注程序的關鍵部分（meat），而不是考慮像數據如何持久存儲這樣的細節問題。貫串代碼的簡單性和一致性將使程序的維護性顯著提高。正如我們將看到的一樣，廣泛使用類繼承增加了生產力和可靠性，并且增強了一致性。這些一致性體現在所展示的代碼中，包括類的行為、數據如何存儲和用戶界面如何呈現數據。由于大部分功能在基類中提供，可以通過快速改變他們的行為來從根本上改變程序。（如用戶交互界面從窗口驅動形式改為以html為基礎）這些基類可以設計為與程序無關，這樣第二個類似的程序將在生產力上立即得到推動。對一個中等的程序一組優秀的基類可以提供高達%50的顯著提升，從時間，開支到可靠性。首先要強調的是切換到真正的面向對象開發并非瑣碎小事，第一次應保證有豐富經驗的協助，或者程序較小且沒有緊急的交付期限；還要說明的是一個面向對象（OO）的解決方案并不是規定在程序中哪些類該用哪些類不該用。如果一家公司開發了自己的可視化控件，或者使用第三方的可視化控件，
核心類
設計任何面向對象程序的第一步是考慮哪些必須的類。這是絕對基本的一步，要有其他各種開發的技術保證，因為早期階段的錯誤要改正將花費昂貴。在設計我們的類時我們一般努力實現低耦合高內聚－類與類之間盡量地獨立，但又可以通過某種強大地方式復合。實現這一目標地一個方式是把類按照在它們程序中所扮演地不同角色來劃分成不同地類別。對這些角色的正確選擇將會形成一組內聚的類。
在對類的角色設計中有一個貫串始終的基本原則：把類的責任分為表現、應用和持久化存儲數據（典型地在數據庫中）。雖然這和三層數據庫程序地劃分是一樣的，要提示的是這種劃分的概念可以在多種環境中實現：從單片機程序到分布式多層程序。組成應用邏輯的這一組類負責最為困難的工作，例如響應用戶操作和處理數據的請求。這一層類中有一部分類表現了真實世界的實體，并被系統所模型化。這些類常被稱為“商業類”或“問題域類”。它們構成任何面向對象程序至關重要的部分，因為其它的類將通過某種方式支持這些類，它們成為所有開發者關注的焦點。
識別一個特定程序中有哪些商業對象一般是經驗的本能，雖然這過程里面有一個完整的學科（或是藝術？）面向對象與傳統技術如SSADM(1)相比的優點貫串于整個分析設計和維持實體的過程：可以通過面向對象分析（OOA）、面向對象設計(OOD)和面向對象編程(OOP)來表現每個商業對象。我們會在后面探尋識別合適的商業對象的部分技巧。首先我們假設下面這些過程已經完成。
不同層（表現、應用和持久）間的類的互相通信已經清楚定義并且相互連接。這些類的關系如圖1
圖中的箭頭顯示同一個層中的類可以調用另一個類中的方法。這張圖同時說明表現層（用戶界面）的類可以操作應用層或用戶界面中的其他類，應用層（商業對象）可以操作應用層的類和調用持久層的方法，持久層只回應應用層的請求。
商業對象
為了演示商業對象是如何實現的，我們接下來將看到一個簡化的程序，其中有庫存，客戶和訂單實體（某個公司提供一定數量的貨物，客戶來買這些貨物）。我們最初的分析確定需要三個商業對象表現這些實體。在我們的Delphi程序中將有三個類：TStockItem, TCustomer 和Torder。清單1中顯示了這些類的公共接口。這里需要指出這些類的特性是通過屬性(
PRoperty)暴露給外部的：這是一個簡單而有益的類設計并且通過屬性控制外部的訪問。還有就是這些屬性應該在類的published區域（原因會在后面提到），并被賦給合適的默認default值。雖然這些屬性限定只在流化類時被用到，會給每個屬性合適的初始值并使代碼更具自描述性。
第一個類框架
在開發程序的初始階段，我們已經識別并實現了三個商業對象。這三個對象扮演共同的角色：通過某種方式表現真實世界的實體。因此我們希望它們和真實世界的實體有相似的屬性和適當的層次。我們將給每個對象一個共同的基類，叫做TPDObject（Problem Domain object）。隨著時間推移我們會在這個類里加入公共的方法和屬性，TPDObject將會不斷得到擴展。需要注意的是TPDObject不要（永遠不要）有任何跟特定程序有關的元素。作為一個程序無關的類它將放在一個獨立的單元并形成框架的基礎：一組可以在許多程序中重用的類。在后面我們的框架會有很大擴展，形成提供重要的程序無關功能的基類，并可以被迅速用于特定的系統。我們TStockItem、TCustomer 和 Torder就是從TPDObject為特定系統定制對象。
TMyAppPDObject是TPDObject的一個繼承類，雖然它的實現部分是空的，但是它是一個很好的示范；如果我們為在特定程序加某些特定元素，并影響程序中所有的問題域類，這樣的類層次應該是比較合適的。清單中列出了框架的初期代碼。類TPDObject還只提供一個只讀屬性ID，它的類型是TobjectID。這個屬性給了每個對象一個標識符：我們將把相同類型和ID的兩個實例認為是同樣的對象。這里ID被故意聲明為自己的類型是為了避免被直接賦給其它標準類型的值。TobjectID的類型并沒有經過特別的選擇：在這里我選擇了整形，在特定情況下它也可能是一個專門的類。雖然用類作ID好像是更純的面相對象，但基于我們的問題域類在程序運行中會被創建、釋放上千次考慮，為了避免創建和釋放對象時額外的負荷，我并沒有這樣做（作為純粹主義論者我把TobjectID包含在TPDObject中作為復合的對象）。在代碼中有一對函數用于轉換字符串和我們的對象標識類型，并且有一個常量作為沒有賦值時的初始值。有很多課堂會提到對象標識：有的說所有的商業對象都應該在創建時被賦予一個程序內不重復的標識（甚至是GUID）。實際上，能在給定的上下文中區分不同的對象才是真正重要的，并且保持這一簡單性將會在性能和存儲空間上有明顯的好處。
關于規范的問題：
為了強化一些設計的理念和設計類框架時的做法我將提一些問題，請讀者思考它們后面的基本原理是什么。我曾提到對于真正的面向對象設計并不禁止使用特定的類，但有一個很重要的例外。這個例外是什么（答案在圖1中）
((( Listing 1 - An
application-specific Problem Domain unit (abridged) )))
unit ProblemDomain;
interface
uses
Framework;
type
TMyAppPDObject = class (TPDObject)
end;
TStockItem = class (TMyAppPDObject)
published
property Name: String;
property QuantityInStock: Cardinal default 0;
property TradePrice: Currency;
property RetailPrice: Currency;
end;
TCustomer = class (TMyAppPDObject) … ;
TOrder = class (TMyAppPDObject) … ;
implementation
end.
((( End Listing 1 )))
((( Listing 2 - An application-independent Framework unit )))
unit Framework;
interface
const
NotAssigned = 0;
type
TObjectID = type Integer;
TPDObject = class
private
FID: TObjectID;
public
property ID: TObjectID read FID default NotAssigned;
end;
function StrToID (Value: String): TObjectID;
function IDToStr (Value: TObjectID): String;
implementation
…
end.
((( End Listing 2 )))
(1) SSADM（Structured Systems Analysis & Systems Design）是1981年英國政府的中央電腦及電訊中心 （Central Computer and Telecommunications Agency ，簡 稱 CCTA ； 網 站 ：
http://www.ccta.gov.uk ）研制的軟件分析設計標準方法。
Phil
ip Brown is a systems design consultant and active developer, presenter, and trainer. He'll promote the benefits of strong OO techniques to deliver better applications given any opportunity. You can contact him at
phil@informatica.uk.com.
