1.4面向对象设计初步 人们把设计视为定义系统的构造蓝图、约定和规则,以指导系统的实现。面向对象方法的一个特点是 OOA和OOD自然地过渡和结合。但仍然有区别:OOA与系统的问题论域更加相关,OOD与系统的实现 更加密切。 本节简要介绍面向对象设计(OOD)的基本要略。 4.1OOD模型 、从面向对象分析到面向对象设计 1、OOA与OOD的比较 从面向对象分析到面向对象设计是一个逐渐扩充模型的过程。面向对象分析主要模拟问题域和系统任 务,而面向对象设计是面向对象分析的扩充,主要是增加各种组成部分 具体来说,面向对象分析识别和定义类-&对象,这些类&-对象直接反映问题域和系统任务。而面向 对象设计识别和定义其它附加类-&-对象,它们反映需求的一种实现。面向对象分析和面向对象设计是开 发系统时的两个不同的阶段。 2、多层次多组成部分模型 多层次多组成部分模型由5层组成,在设计期间主要扩充为4个部分 (1)人机交互部分:有效的人机交互所必需的实际显示和输入。设计一组有关类接口视图的用户模 型的类和对象,设计用户界面 (2)问题域部分:面向对象分析的结果放在问题域部分。在该部分中,需要管理面向对象分析的某 些类-&-对象、结构、属性和方法的组合与分解。原因可能是时间与空间的折中、内存管理、开发人员的 变更及类的调整等。设计构造一组为底层应用建立模型的类和对象,细化分析结果 (3)任务管理部分:任务定义、通讯和协调,也包括硬件分配、外部系统以及装置协议。即确定系 统资源的分配,设计用于系统中类的行为控制的对象/类; (4)数据管理部分:对永久性数据的访问和管理。即确定系统持久对象的存储,将对象转换成数据 库记录或表格; 主题层 类-&对象层 结构层 人机交互部分间题域部分任务管理部分数据管理部分 属性层 方法层 多层次、多组成部分模型 详细地确定对象和类是OOD的关键工作。一种有效的启发式方法是对需要提供的服务和问题陈述作 语法分析,其中名词和名词短语可作候选对象,动词是候选对象服务,形容词表示了可能的子类关系。设 计经验和技巧是非常重要的 在分析和设计中,要注意遵循这样的原则:把构造由基本对象组装成复杂对象或活动对象的过程与分 解大粒度对象使系统细化过程相结合:把抽象化与具体化结合起来,把独立封装与继承关系结合起来等。 面向对象设计 1、面向对象设计范式 设计范式是用其分解过程的观点来刻划的。过程范式采用面向任务的观点。当提出一种解决目标问题 时,所提出的解决方法是通过将其分解成一系列任务来完成的,这些任务形成了过程应用程序的基本结构。 分析阶段开发的信息可以作为设计阶段的输入部分,但它是以不同于设计阶段的术语表示的。由于这种原 因,传统的软件生命周期观点包含了分析和设计之间的不必要的界限。导致了从分析阶段的问题域到设计
1．4 面向对象设计初步 人们把设计视为定义系统的构造蓝图、约定和规则，以指导系统的实现。面向对象方法的一个特点是 OOA 和 OOD 自然地过渡和结合。但仍然有区别：OOA 与系统的问题论域更加相关，OOD 与系统的实现 更加密切。 本节简要介绍面向对象设计（OOD）的基本要略。 1．4．1 OOD 模型 一、从面向对象分析到面向对象设计 1、OOA 与 OOD 的比较 从面向对象分析到面向对象设计是一个逐渐扩充模型的过程。面向对象分析主要模拟问题域和系统任 务，而面向对象设计是面向对象分析的扩充，主要是增加各种组成部分。 具体来说，面向对象分析识别和定义类-&-对象，这些类-&-对象直接反映问题域和系统任务。而面向 对象设计识别和定义其它附加类-&-对象，它们反映需求的一种实现。面向对象分析和面向对象设计是开 发系统时的两个不同的阶段。 2、 多层次 多组成部分模型 多层次 多组成部分模型由 5 层组成，在设计期间主要扩充为 4 个部分。 （1）人机交互部分：有效的人机交互所必需的实际显示和输入。设计一组有关类接口视图的用户模 型的类和对象，设计用户界面； （2）问题域部分：面向对象分析的结果放在问题域部分。在该部分中，需要管理面向对象分析的某 些类-&-对象、结构、属性和方法的组合与分解。原因可能是时间与空间的折中、内存管理、开发人员的 变更及类的调整等。设计构造一组为底层应用建立模型的类和对象，细化分析结果； （3）任务管理部分：任务定义、通讯和协调，也包括硬件分配、外部系统以及装置协议。即确定系 统资源的分配，设计用于系统中类的行为控制的对象/类； （4）数据管理部分：对永久性数据的访问和管理。即确定系统持久对象的存储，将对象转换成数据 库记录或表格； 详细地确定对象和类是 OOD 的关键工作。一种有效的启发式方法是对需要提供的服务和问题陈述作 语法分析，其中名词和名词短语可作候选对象，动词是候选对象服务，形容词表示了可能的子类关系。设 计经验和技巧是非常重要的。 在分析和设计中，要注意遵循这样的原则：把构造由基本对象组装成复杂对象或活动对象的过程与分 解大粒度对象使系统细化过程相结合；把抽象化与具体化结合起来，把独立封装与继承关系结合起来等。 二、面向对象设计 1、面向对象设计范式 设计范式是用其分解过程的观点来刻划的。过程范式采用面向任务的观点。当提出一种解决目标问题 时，所提出的解决方法是通过将其分解成一系列任务来完成的，这些任务形成了过程应用程序的基本结构。 分析阶段开发的信息可以作为设计阶段的输入部分，但它是以不同于设计阶段的术语表示的。由于这种原 因，传统的软件生命周期观点包含了分析和设计之间的不必要的界限。导致了从分析阶段的问题域到设计
阶段的求解决域的不一致。 面向对象的设计范式采用建模的观点。在传统的软件生命周期中,分析和设计同开发问题域的模型紧 密相关。而在面向对象的生命周期中,保留了明显的独立结构。人们通过把问题域作为一系列相互作用的 实体可以构造出模型。实体的基于软件模型以及模型间的关系汇集成应用程序的基本结构。这样,在分析 阶段开发的信息就成为设计阶段的一个主要部分。这种极其自然的过渡是利用了“构件”的一致性。这种 致性与结构化分析和结构化设计有着完全不同的观点。 由过程设计范式产生的构件是执行任务的过程,且与所提出的解决方法有关。 由面向对象范式产生的构件是实体描述,即类。许多这样的描述可直接地反映原始问题,尽管许多类 并不表示物理对象,但它们是概念上的实体,可以用问题域的术语来描述 在传统语言中,程序是由传递参数的过程或函数的集合组成,每个过程处理它的参数,并有可能返回 个值,因此执行单元(即过程)为中心。 在面向对象的语言中,世界被看作独立的对象的集合,相互之间通过过程(通常称作消息)进行通信 对象是主动的,而过程(消息)是被动的,过程(消息)和它们的参数一起被从一个对象传递到另一个对 象。一个对象根据提交给它的请求(即过程过又称做方法)并基于这些过程(方法)进行行动,因此以数 据(即对象)为中心。由于抽象数据类型普遍地被应用于模拟应用领域内的实体,它们为程序的模块化提 供了一个自然的基础,其面向对象程序的机构可以非常相似于应用领域中的结构。 为了说明过程范式和面向对象范式的不同,下面以一个十字路口控制交通灯的软件系统为例子,其简 要的需求说明如下 硬件包括一组传感器、交通灯和控制箱。软件读出传感器的状态,决定十字路口的新状态并且发出改 变交通灯的信号。另外,系统还有其他能力,如通过配置集测试循环灯的任选项。系统也可以被设置成缺 省状态。传感器指明在特殊车道上有无车辆。有几种类型的传感器,每种传感器的内部工作方式都不同。 然而所有的传感器都是中断驱动的,且一旦触发,就置传感器状态位。当决定要改变十字路口的状态时, 需要重新设置每个传感器。这个特殊的十字路口用两种类型的交通灯:一种是常见的三色灯,它用于直接 向前车道:另一种是四方位灯:红、黄、绿和转动箭头标志。每个灯都有当前状态、下一个状态和缺省状 态。控制器的硬件包括灯的开关、传感器的数据存储以及进行定时查询状态的时钟。控制器的软件读时钟 定时查询传感器,确定下一个状态并且发信号改变交通灯。 过程范式通过考虑必须执行的一组任务来开发交通控制系统。如下图所示。层次结构中的每一层表示 了更详细的功能。图中任务的顺序是从左到右的 [控制十字路口交通灯 设置初始序列[检查时钟][读传感器]确定下一状态[修改状态 [定时查询每个传感器设置每个传感器字位] 控制十字路口交通灯问题的层次图 面向对象范式通过识别问题的实体来开发系统。本例涉及到的物理实体包括传感器、交通灯的控制器 注意,范式并不仅限于物理实体。如本例可识别的非物理实体是“lane”(车道)实体,它把传感器与特定 的交通灯联系起来。“lane”实体沟通了问题域和求解域之间的关系。 这些实体的抽象将成为系统的基本成分类,类的规格说明用来补充传统的需求说明的信息。面向对象 的需求说明用对象和分类把传统的系统功能需求与面向对象的操纵的对象描述融合在一起,它描述了问题 域的一部分。 上面识别的实体以及其他一些实体,如下图所示。这种图用实体关系图来表示实体和实体间的关系, 称这种图是问题的语义数据模型。它允许表示更宽范围的信息
阶段的求解决域的不一致。 面向对象的设计范式采用建模的观点。在传统的软件生命周期中，分析和设计同开发问题域的模型紧 密相关。而在面向对象的生命周期中，保留了明显的独立结构。人们通过把问题域作为一系列相互作用的 实体可以构造出模型。实体的基于软件模型以及模型间的关系汇集成应用程序的基本结构。这样，在分析 阶段开发的信息就成为设计阶段的一个主要部分。这种极其自然的过渡是利用了“构件”的一致性。这种 一致性与结构化分析和结构化设计有着完全不同的观点。 由过程设计范式产生的构件是执行任务的过程，且与所提出的解决方法有关。 由面向对象范式产生的构件是实体描述，即类。许多这样的描述可直接地反映原始问题，尽管许多类 并不表示物理对象，但它们是概念上的实体，可以用问题域的术语来描述。 在传统语言中，程序是由传递参数的过程或函数的集合组成，每个过程处理它的参数，并有可能返回 一个值，因此执行单元（即过程）为中心。 在面向对象的语言中，世界被看作独立的对象的集合，相互之间通过过程（通常称作消息）进行通信。 对象是主动的，而过程（消息）是被动的，过程（消息）和它们的参数一起被从一个对象传递到另一个对 象。一个对象根据提交给它的请求（即过程过又称做方法）并基于这些过程（方法）进行行动，因此以数 据（即对象）为中心。由于抽象数据类型普遍地被应用于模拟应用领域内的实体，它们为程序的模块化提 供了一个自然的基础，其面向对象程序的机构可以非常相似于应用领域中的结构。 为了说明过程范式和面向对象范式的不同，下面以一个十字路口控制交通灯的软件系统为例子，其简 要的需求说明如下： 硬件包括一组传感器、交通灯和控制箱。软件读出传感器的状态，决定十字路口的新状态并且发出改 变交通灯的信号。另外，系统还有其他能力，如通过配置集测试循环灯的任选项。系统也可以被设置成缺 省状态。传感器指明在特殊车道上有无车辆。有几种类型的传感器，每种传感器的内部工作方式都不同。 然而所有的传感器都是中断驱动的，且一旦触发，就置传感器状态位。当决定要改变十字路口的状态时， 需要重新设置每个传感器。这个特殊的十字路口用两种类型的交通灯：一种是常见的三色灯，它用于直接 向前车道；另一种是四方位灯：红、黄、绿和转动箭头标志。每个灯都有当前状态、下一个状态和缺省状 态。控制器的硬件包括灯的开关、传感器的数据存储以及进行定时查询状态的时钟。控制器的软件读时钟， 定时查询传感器，确定下一个状态并且发信号改变交通灯。 过程范式通过考虑必须执行的一组任务来开发交通控制系统。如下图所示。层次结构中的每一层表示 了更详细的功能。图中任务的顺序是从左到右的。 面向对象范式通过识别问题的实体来开发系统。本例涉及到的物理实体包括传感器、交通灯的控制器。 注意，范式并不仅限于物理实体。如本例可识别的非物理实体是“lane”（车道）实体，它把传感器与特定 的交通灯联系起来。“lane”实体沟通了问题域和求解域之间的关系。 这些实体的抽象将成为系统的基本成分类，类的规格说明用来补充传统的需求说明的信息。面向对象 的需求说明用对象和分类把传统的系统功能需求与面向对象的操纵的对象描述融合在一起，它描述了问题 域的一部分。 上面识别的实体以及其他一些实体，如下图所示。这种图用实体关系图来表示实体和实体间的关系， 称这种图是问题的语义数据模型。它允许表示更宽范围的信息
ITripSensor SunlIght IStraightLight Is a Traffic Light I Controller controls is part_of is_part_of > is part_of Clock is_part-of Intersection is part_ of>· H Direction 控制十字路口交通灯问题的实体关系图 比较上面两图中的信息,可说明两种范式观点上的不同。在过程抽象时,过程范式必须考虑设计过程 中数据表示所必须的结构。同样地,面向对象范式在设计中需要操纵一个对象的操作符时,可能采用功能 分解法。 在构造面向对象的系统,分析阶段的工作与设计阶段的工作联系的更加紧密,这是因为有公共的对象 模型。在分析阶段,分析者确定了问题域对象;而在设计阶段,设计者为特定的基于计算机的解规定了额 外的必要的对象,有关实现级的对象还需重复设计过程。 2、实体和实体间的关系 面向对象的设计首先涉及到的是实体。实体可以是现实中的对象,如交通灯、椅子、飞机,也可以是 抽象概念,如作用、相互影响或事故(飞行)。 实体间的关系指发生在问题域中的对象间的相互作用。飞行员“驾驶”飞机,“驾驶”就是飞行员和 飞机之间的一种关系。这种关系是应用级并且用问题域术语来表示的。两个实体之间的关系可能不止一种 个实体可能与其它的几个实体有关系 面向对象范式的一种重要设计关系是继承关系。如为了描述类 pilot(飞行员),设计者可能希望从类 person(人)的描述开始,利用继承机制可把 person的所有行为和属性都加到 pilot的定义中去 面向对象范式的另一种设计关系是成分关系。有关 person的描述可能包含名字属性,通过声明一个字 符串类实例就可在 person中定义这个属性 继承关系和成分关系之间的区别是:继承关系表示现有定义的特化,如飞行员和人。成分关系用于在 类的实现中提供的一种服务设施,如人与字符串 3、完整的数据模型 面向对象的设计包括类设计和应用设计两个部分,并且被融合在应用开发中。类设计可以隐含在应用 设计中,而应用设计包括确定问题域中的各种实体以及实现求解的一些特定实体。每个实体的类型都引出 类描述,一旦开发出概念上完整的类描述,就可以设计出应用系统。通过连接类实例(对现实世界建模), 利用它们相互间的作用,从而产生问题的解 类描述包括三部分:属性定义、类接口描述和类实例的可能状态之间的有效变换集。下面考虑设计栈 的例子,如下图所示。图(a)说明栈的数据属性,包括栈中的若干数据存储和栈操作方法;图(b)给出
比较上面两图中的信息，可说明两种范式观点上的不同。在过程抽象时，过程范式必须考虑设计过程 中数据表示所必须的结构。同样地，面向对象范式在设计中需要操纵一个对象的操作符时，可能采用功能 分解法。 在构造面向对象的系统，分析阶段的工作与设计阶段的工作联系的更加紧密，这是因为有公共的对象 模型。在分析阶段，分析者确定了问题域对象；而在设计阶段，设计者为特定的基于计算机的解规定了额 外的必要的对象，有关实现级的对象还需重复设计过程。 2、实体和实体间的关系 面向对象的设计首先涉及到的是实体。实体可以是现实中的对象，如交通灯、椅子、飞机，也可以是 抽象概念，如作用、相互影响或事故（飞行）。 实体间的关系指发生在问题域中的对象间的相互作用。飞行员“驾驶”飞机，“驾驶”就是飞行员和 飞机之间的一种关系。这种关系是应用级并且用问题域术语来表示的。两个实体之间的关系可能不止一种。 一个实体可能与其它的几个实体有关系。 面向对象范式的一种重要设计关系是继承关系。如为了描述类 pilot（飞行员），设计者可能希望从类 person（人）的描述开始，利用继承机制可把 person 的所有行为和属性都加到 pilot 的定义中去。 面向对象范式的另一种设计关系是成分关系。有关 person 的描述可能包含名字属性，通过声明一个字 符串类实例就可在 person 中定义这个属性。 继承关系和成分关系之间的区别是：继承关系表示现有定义的特化，如飞行员和人。成分关系用于在 类的实现中提供的一种服务设施，如人与字符串。 3、 完整的数据模型 面向对象的设计包括类设计和应用设计两个部分，并且被融合在应用开发中。类设计可以隐含在应用 设计中，而应用设计包括确定问题域中的各种实体以及实现求解的一些特定实体。每个实体的类型都引出 类描述，一旦开发出概念上完整的类描述，就可以设计出应用系统。通过连接类实例（对现实世界建模）， 利用它们相互间的作用，从而产生问题的解。 类描述包括三部分：属性定义、类接口描述和类实例的可能状态之间的有效变换集。下面考虑设计栈 的例子，如下图所示。图（a）说明栈的数据属性，包括栈中的若干数据存储和栈操作方法；图（b）给出
栈的公共接口;图(c)状态图说明栈的有效状态序列。 (a)data: array [l.. someenumber] of (c) termtype top:integer push pop is full 满 make_empty create 栈的三个部分 类实例间相互作用的模式确定了应用系统的结构。这些相互作用是类与类之间的关系模型。可以用几 种方法为这些关系建模,但它们都应包括消息在内。传递消息可以是同步的,也可以是异步的,这依赖于 执行模式的选择 语义数据模型提供了支持开发应用程序的完整的数据模型,这种应用程序包含有高级应用关系和低级 类定义关系。下图给出了上面所述的飞行员/飞机应用片段的实体关系图 rli is employed by flies I airplane s a person 飞行员/飞机应用的实体关系图 这样,开发一个面向对象应用系统就成为组合类描述和应用系统结构。许多过程都是由现实世界的问 题域来指导的,而不是用我们求解问题的观点。这就形成在高层包含问题域模型的应用设计。应用设计过 程从顶层开始,经过识别类到低层,然后基于低层定义来设计低层类,再进行向上设计 4、类的设计准则 在任何面向对象的应用中,类实例是系统的主要组成部分,而且如果采用纯面向对象的方法,那么整 个系统就是由类实例组成的。因此,每个独立的类的设计对整个应用系统都有影响。下面简单介绍进行类 的设计时要考虑的因素 (1)类的公共接口的单独成员应该是类的操作符 (2)类A的实例不应该直接发送消息给类B的成分 (3)操作符是公共的当且仅当类实例的用户可用 (4)属于类的每个操作符要么访问要么修改类的每个数据 (5)类必须尽可能少地依赖其他类
栈的公共接口；图（c）状态图说明栈的有效状态序列。 类实例间相互作用的模式确定了应用系统的结构。这些相互作用是类与类之间的关系模型。可以用几 种方法为这些关系建模，但它们都应包括消息在内。传递消息可以是同步的，也可以是异步的，这依赖于 执行模式的选择。 语义数据模型提供了支持开发应用程序的完整的数据模型，这种应用程序包含有高级应用关系和低级 类定义关系。下图给出了上面所述的飞行员／飞机应用片段的实体关系图。 这样，开发一个面向对象应用系统就成为组合类描述和应用系统结构。许多过程都是由现实世界的问 题域来指导的，而不是用我们求解问题的观点。这就形成在高层包含问题域模型的应用设计。应用设计过 程从顶层开始，经过识别类到低层，然后基于低层定义来设计低层类，再进行向上设计。 4、 类的设计准则 在任何面向对象的应用中，类实例是系统的主要组成部分，而且如果采用纯面向对象的方法，那么整 个系统就是由类实例组成的。因此，每个独立的类的设计对整个应用系统都有影响。下面简单介绍进行类 的设计时要考虑的因素： （1）类的公共接口的单独成员应该是类的操作符； （2）类 A 的实例不应该直接发送消息给类 B 的成分； （3）操作符是公共的当且仅当类实例的用户可用； （4）属于类的每个操作符要么访问要么修改类的每个数据； （5）类必须尽可能少地依赖其他类；
(6)两个类之间的相互作用应该是显式的; (7)采用子类继承超类的公共接口,开发子类成为超类的特化 (8)继承结构的根类应该是目标概念的抽象模型。 前4条准则着重讲述类接口的适当形式和使用 准则1要求的信息隐蔽增强了开发表示独立的设计 准则2进一步说明了这种封装性,它禁止访问用作为类的部分表示的类实例。这些准则都强调了一个 类是由其操作集来刻划的,而不是其表达的思想。 准则3把公共接口定义为在类表示中包含了全部的公共操作集。 准则4要求属于类的每个操作符都必须表示其建模的概念行为 这4条准则为设计者指明了开发,分解类接口以及类表示的方向 后4条准则着重考虑类之间的关系。 准则5要求设计者尽可能少地连接一个类与其它类。如果一个正被设计的类需要另一个类的许多设施 的话,也许这种功能应表示成一个新类。 准则6试图减少或者消除全局信息。一个类所需要的任何信息都应该从另一个类中用参数显式地传递 给它。 准则7禁止使用继承性开发新类的公共接口之外的部分。利用类实例作为另一个类的部分表示的最佳 方法是,在新设计的类表示中声明支持类实例 准则8鼓励设计者开发类的继承结构,这种类是抽象的特化。这些抽象导致了更多的可重用子类,并 确定了子类之间的不同。 4.2什么是优良的OOD 个优良的OOD应具备的基本条件 (1)类与类的继承必须具有高度凝集性; (2)类与类之间的耦合应该很松散。只有一个例外,具有类的继承关系必须是紧密联系的,因而子 类与父类要紧密耦合 (3)某个类的数据实现细节对于别的类来说应该是隐藏的 (4)设计应该具有最优的可重用性; (5)尽力使类、对象和方法的定义具有简单性 (6)对所设计的类和类族,应注意保持其协议或接口的稳定性 (7)类的层次结构设计规模适度,不要太深或太浅 (8)系统整体规模要最小化 4.3对象标识设计 对象标识的目的是明确地区别对象,要求在一系统中,对象标识具有唯一性、稳定性和一致性。 在对象/类的标识方法中,有几种实用的设计方式 (1)以间接地址标识对象。如在 Smalltalk80中,就是以对象指针指向一个对象表作对象标识,这种 方法支持数据的独立性 (2)以结构化标识符标识对象。这类似于C++的变量命名,而且隐式类/对象的层次及指示的逻辑 (3)以代名词标识对象。在DBMS中广泛采用这种使用关键字的做法,易于记忆,但也易于非唯 非连续。 (4)以内部编号标识对象。 (5)类似于指针的另一种对象标识是引用。引用将一个新的标识符与对象联系起来,这样可以在程
（6）两个类之间的相互作用应该是显式的； （7）采用子类继承超类的公共接口，开发子类成为超类的特化； （8）继承结构的根类应该是目标概念的抽象模型。 前 4 条准则着重讲述类接口的适当形式和使用。 准则 1 要求的信息隐蔽增强了开发表示独立的设计。 准则 2 进一步说明了这种封装性，它禁止访问用作为类的部分表示的类实例。这些准则都强调了一个 类是由其操作集来刻划的，而不是其表达的思想。 准则 3 把公共接口定义为在类表示中包含了全部的公共操作集。 准则 4 要求属于类的每个操作符都必须表示其建模的概念行为。 这 4 条准则为设计者指明了开发，分解类接口以及类表示的方向。 后 4 条准则着重考虑类之间的关系。 准则 5 要求设计者尽可能少地连接一个类与其它类。如果一个正被设计的类需要另一个类的许多设施 的话，也许这种功能应表示成一个新类。 准则 6 试图减少或者消除全局信息。一个类所需要的任何信息都应该从另一个类中用参数显式地传递 给它。 准则 7 禁止使用继承性开发新类的公共接口之外的部分。利用类实例作为另一个类的部分表示的最佳 方法是，在新设计的类表示中声明支持类实例。 准则 8 鼓励设计者开发类的继承结构，这种类是抽象的特化。这些抽象导致了更多的可重用子类，并 确定了子类之间的不同。 1．4．2 什么是优良的 OOD 一个优良的 OOD 应具备的基本条件： （1）类与类的继承必须具有高度凝集性； （2）类与类之间的耦合应该很松散。只有一个例外，具有类的继承关系必须是紧密联系的，因而子 类与父类要紧密耦合； （3）某个类的数据实现细节对于别的类来说应该是隐藏的； （4）设计应该具有最优的可重用性； （5）尽力使类、对象和方法的定义具有简单性； （6）对所设计的类和类族，应注意保持其协议或接口的稳定性； （7）类的层次结构设计规模适度，不要太深或太浅； （8）系统整体规模要最小化。 1．4．3 对象标识设计 对象标识的目的是明确地区别对象，要求在一系统中，对象标识具有唯一性、稳定性和一致性。 在对象／类的标识方法中，有几种实用的设计方式： （1）以间接地址标识对象。如在 Smalltalk80 中，就是以对象指针指向一个对象表作对象标识，这种 方法支持数据的独立性。 （2）以结构化标识符标识对象。这类似于 C++的变量命名，而且隐式类／对象的层次及指示的逻辑 范围。 （3）以代名词标识对象。在 DBMS 中广泛采用这种使用关键字的做法，易于记忆，但也易于非唯一、 非连续。 （4）以内部编号标识对象。 （5）类似于指针的另一种对象标识是引用。引用将一个新的标识符与对象联系起来，这样可以在程