封裝：軟件對象就是包含模擬真實世界的對象的物理屬性（數據）和功能（行為）的離散包。例如，帳戶對象保持收支平衡并且包含平衡中的借貸機制。
信息隱藏：結構良好的對象有簡單的接口，并且不向外界顯漏任何內部機制。真實世界信息隱藏的例子是，您不需要詳細了解汽車的工作原理就能夠駕駛它。
類和實例：類是定義特定類型的軟件對象具有什么類型的屬性和行為的模板，而實例是具有這些屬性值的個別對象。創建類的新實例稱為實例化。利用生物學進行類比，人就是一個類。所有的人都具有一些屬性，比如身高、體重、頭發和眼睛顏色等等。我們中的每個人都是這個類 HumanBeing 的實例，具有一些特定的身高、體重以及其他的屬性值。類是一直存在的，而實例具有有限的生命周期。
關聯和繼承：在 OO 中，表達類和對象之間的關聯的能力是一個關鍵的概念；繼承是關聯的強形式，用于表達有關系：按照同樣的方式，生物物種由這樣的層次構成：界 (Kingdom)、門 (Phylum)、綱 (Class)、目 (Order)、科 (Family)、類 (Genus)、種 (Species)。我們常常發現軟件對象的自然層次。例如，當您創建一個財務應用程序實體時，您可能需要構造像經常帳戶（CheckingAccount）、儲蓄帳戶（SavingsAccount）和貸款帳戶（LoanAccount）這樣的對象。如果您看得更仔細一點（請參見圖 3），您將發現這些類共享許多屬性，比如都有收支平衡帳戶、借方帳戶和貸方帳戶等等
圖 3. UML 類繼承示例
與其重復定義和管理這些屬性的代碼，不如創建一個通用的帳戶（Account）類，該類具有現金收支平衡并且可以處理借貸事務。所有其他的類都是這個帳戶（Account）對象的專門形式。例如，貸款帳戶（LoanAccount）將在零和某個約定的最大值之間具有負平衡，而儲蓄帳戶（SavingsAccount）將具有負平衡，并且將展示增加利息的行為，等等。
消息傳遞：為了完成一些有用的工作，軟件對象需要相互通信。它們通過相互發送消息來這樣做。例如，假定我們想將 $1000 從經常帳戶轉到儲蓄帳戶，要達到此目的，可以將帶有參數 $1000 的借消息發送到經常帳戶（CheckingAccount）實例，并且將相應的貸消息發送到儲蓄帳戶（SavingsAccount）實例。當實例接收消息時，它執行相應的功能，稱為方法，它有與消息相同的名稱。
多態：這個術語描述兩個或兩個以上的類接受相同的消息但是以不同的方式進行實現的情況。例如，自由經常帳戶（FreeCheckingAccount）實例和經常帳戶（CheckingAccount）實例將響應借 ($100) 消息，但是自由經常帳戶（FreeCheckingAccount）實例將正好 $1000 記入它的帳戶平衡的借方，而經常帳戶（CheckingAccount）實例將 $1000 加上交易費記入它的帳戶平衡的借方。
OO 支持應用程序分析、設計和開發的完整生命周期：
OOAD 試圖找到最優的對象和最自然的類繼承來實現它們。
OO 開發集中于應用程序的漸進式開發，每次實現一個業務場景或用況。像 IBM WebSphere Studio Application Developer 這樣的工具有助于開發人員快速地構造和測試 OO 應用程序。
OO 運行時環境，例如由 Java 虛擬機提供的，提供應用程序服務（如垃圾收集（刪除因使用它們的對象已經被丟棄而不再使用的資源））以及框架（如 J2EE）來為駐留在不同的服務器上的對象提供相互通信的機制。
目前與 SO 有關的 OO 設計實踐的主要問題在于，它的粒度級別集中在類級，對于業務服務建模來說，這樣的抽象級別太低了。諸如繼承這樣的強關聯產生了相關方之間一定程度的緊耦合（因而具有依賴性）。與此相反，SO 范式試圖通過松耦合來促進靈活性和敏捷性。目前，在 SOA 中還沒有服務實例的跨平臺繼承支持和一流的表示法來避免需要處理服務生命周期維護管理問題（如遠程垃圾收集）。
這些考慮事項使 OO 難以與 SO 體系結構樣式直接保持一致。然而，對于設計已定義的服務中的底層類和組件結構，OO 仍然是一種有價值的方法。此外，許多 OOAD 技術（例如類、責任、協作（CRC）卡）也可以用于服務建模（如果它們提升到更高層次的抽象的話）。在本文后面，我們將回過頭來討論這一點。
圖 4 展示了可見性層次和 OO、面向組件 和 SO 設計提供的重點之間的對應關系。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關系。
圖 4. 設計層次
至于表示法，統一建模語言（Unified Modeling Language，UML）——通過一些附加的定型（Stereotype）和概要加以增強——自然成為 SOAD 的重要基礎。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
