封装：软件对象就是包含模拟真实世界的对象的物理属性（数据）和功能（行为）的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
类和实例：类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而实例是具有这些属性值的个别对象。创建类的新实例称为实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 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 的重要基础。
文章来源于领测软件测试网 https://www.ltesting.net/
