面向对象的分析和设计

第一篇：面向对象的分析和设计

面向对象分析与设计课程总结

面向对象分析与设计

课程总结

0923010208 指导老师：庄育飞

这学期学院开设了面向对象分析与设计(UML)这门课，通过老师的讲解，自己一些相关书籍的阅读和实践作业的完成，逐步对课程有了由浅及深的认识。我觉得学习这门课还是受益匪浅的。

面向对象(Object Oriented,OO)是一门以实践为主课程，课程中可以分开两块OOA(面向对象系统分析)和OOD(面向对象系统设计)。

OOA(面向对象系统分析)主要内容: 研究问题域和用户需求,运用面向对象的观点和原则发现问题域中与系统责任有关的对象,以及对象的特征和相互关系.OOA不涉及针对具体实现采取的设计决策和有关细节,独立于具体实现的系统模型。是一个完整确切反映问题域和用户需求的系统模型。OOA的优势：复

用、可扩展、可维护性、弹性。

OOD(面向对象系统设计)：以OOA模型为基础，按照实现的要求进行设计决策，包括全局性的决策和局部细节的设计，与具体的实现条件相关。OOD的步骤：细化重组类→细化和实现类之间的关系，明确其可见性→增加属性,指定属性的类型和可见性→分配职责,定义执行每个职责的方法→对消息驱动的系统,明确消息传递的方式→利用设计模式进行局部设计→画出详细的类图和时序图。

面向对象的分析与设计方法将致力于解决传统软件研发过程中由于软件模块化结构化程度不高带来的软件重用性差、软件可维护性差、开发出的软件不能满足用户需要等方面问题。面向对象的概念包括：对象、对象的状态和行为、类、类的结构、消息和方法。对象概念将包含对象唯一性、抽象性、继承性、多态性的重要特征。面向对象的要素包含：抽象、封装性、共享性三方面。

在设计模式的研究过程中，我们组选择的是迭代器(Iterator)的设计模式研究。完成设计研究后，我对迭代器的设计模式有了更为深刻的理解。迭代器(Iterator)提供一个方法顺序访问一个聚合对象的各个元素，而又不暴露该对象的内部表示。并了解到迭代器设计模式一般在以下三类场合使用较多。

 访问一个聚合对象的内容而无需暴露它的内部表示。

 支持对聚合对象的多种遍历。因为遍历状态是保存在每一个迭代器对象中的。

 为遍历不同的聚合结构提供一个统一的接口。根据实现方式的不同，效果上会有差别。同时还简化了容器的接口。但是在java Collection中为了提高可扩展性，容器还是提供了遍历的接口。

在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的：一是集合内部的数据存储结构，二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则，所以我们要尽可能的去分解这些职责，用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。

在Java Collection的应用中，提供的具体迭代器角色是定义在容器角色中的内部类。这样便保护了容器的封装。但是同时容器也提供了遍历算法接口，你可以扩展自己的迭代器。至于迭代器模式的使用。客户程序要先得到具体容器角色，然后再通过具体容器角色得到具体迭代器角色。这样便可以使用具体迭代器角色来遍历容器了。

OOA和OOD之间没有明显的界限。OOA与OOD的不可分割性正好说明了OO思想的强大，即软件过程阶段的无缝连接，在交流与沟通中不会产生鸿沟，这是相对结构化思想的好处，因为从功能模块到某块详细控制逻辑设计两者之间的联系不是十分紧密，需要分析人员与设计人员的再沟通。

通过课程的学习与实践，对面向对象的理念，以及相关方法，设计模式有了更为深刻的理解与掌握。针对面向对象的分析与设计课程的授课内容及方法，我个人觉得对我还是有不少的帮助和 提高。结合自己的工作，

虽然与开发接触的比较少，但是在运维过程中，如果能了解开发原理，结合实际的工作，会对一些源代码的分析能力以及工作效率的提高起到明显的帮助作用。

庄老师上课经常说一些与课程无关的内容，我已开始并不理解他的作法，后来我慢慢认识到面向对象分析设计的学习就是培养思想的一种过程，这种思维方式还是需要大量的实践才能灵活的运用。目前的阶段，只能说是知道有这样一种设计思想、这种解决问题的方案，至于在何时应该使用、如何去使用，就需要在今后的经验中去累积了。

下面是一些我掌握的基础知识

9种UML图：

类 图：描述类的结构(包括属性以及类之间的相互关系)

对象图：对象以及对象之间的相互关系

构件图：构件及其相互依赖关系

部署图：构件在各节点上的部署

顺(时)序图：强调时间顺序的交互图，用于将系统行为分配给类。一般包含了边界、控制、实体对象

协作图：强调对象协作的交互图，与时序图同构

状态图：类所经历的各种状态，包括状态之间的转换以及触发转变的事件

活动图：对工作流程建模

用例图：与用例文档结合进行需求捕获，测试依据

面向对象设计七个原则：

开-闭 原则、里氏转换原则、依赖倒转原则、接口隔离原则、组合/聚合复用原则、迪米特法则、单一职责

ICONIX开发过程：域模型——用例文档——健壮性分析——健壮图——时序图

设计模式：

1)创建模式: 涉及对象的创建

单例模式, 工厂模式, 建造者模式，原型模式

2)结构模式:涉及类和对象的组合

Facede外观模式, 代理模式, 适配器模式, 装饰模式

3)行为模式: 刻画了类和对象交换及分配职责的方式.主要目标是解耦

观察者模式, 命令模式, 模板模式

本学期学了《面向对象系统分析与设计》课程，本课程我们主要是学习了面向对象的统一建模语言UML,了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在IBM RSA软件环境下用UML进行分析和设计的技术。在《面向对象系统分析与设计》

的上级课程上，我们的实践能力方面着重设计构思和设计技能的得到基本训练，熟练的上机操作能力和分析能力，加深理解、验证、巩固课堂教学内容。

数据库是以信息处理为核心的任何应用系统的基础，数据库设计的质量直接关系到系统开发的成败和优劣。数据库设计的方法与系统使用的开发方法有着密切的关系，同时还与所应用的数据库模型(层次模型、网状模型、关系模型、对象模型)有关。目前经常采用E—R(Entity—Relationship)图的方法设计数据库。但E—R图设计数据库存在的主要问题是只能对资料建模，而不能对行为建模。而UML类图的描述能力更强，UML类图是E—R图的扩充。对于关系模型来说，可以用类图描述数据库模式，用类描述数据库表。

UML是应用面向对象方法进行系统开发的全程建模语言，可用于业务分析、需求分析、系统设计、系统实现与测试等系统开发的各个环节。 UML概念设计的基本工作分为两个方面：

· 一是从系统分析和系统设计所建立的各种类图中抽取持久型类。

· 二是确定持久型类之间的关系，并用类图描述这种关系，从而把类图作为数据

库概念设计的结果。

1.抽取持久型类

持久型类是指类的完整信息需要在数据库中存储的类。在UML中，类可以分为

边界类、实体类和控制类三种类型。

· 接口类和控制类的信息一般不需要长久存储。

· 持久型类只可能是实体类，但并不是所有实体类的信息都需要长久地存储，持久型类只需要从那些信息需要长久存储的实体类中抽取。

2.确定类关系

在比较复杂的系统分析和设计中，并没有建立立足于整个系统的整体类图，而只是建立了一个个针对具体用例的类图。也就是说，所提取的持久型类被分散到各个用例类图当中了。因此，需要对抽取的持久型类进行分析，以确定它们之间的相互关系，建立起反映这些类关系的类图。

UML数据建模与E—R图有着本质的区别。在E—R图中，应用型数据库系统的重点是数据库结构。概念设计是应用型数据库系统开发的重点和难点。而UML是用于面向对象系统开发的全程建模语言，可用于需求分析、系统分析与设计、系统实现、系统测试等系统开发的所有环节。由于UML基于面向对象技术，而要保持方法的一致性，最好选择面向对象数据库。但是，目前的面向对象数据库在实现技术上还不十分成熟，即使应用面向对象技术和环境开发应用系统，通常的做法是使用UML进行建模，用关系型数据库储存和管理数据。

通过一学期的学习和实践，我了解到uml具有以下特点[1]：

(1)面向对象。uml支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。

(2)可视化，表示能力强。通过uml的模型图能清晰地表示系统的逻辑模型和实现模型。可用于各种复杂系统的建模。

(3)独立于过程。uml是系统建模语言，独立于开发过程。

(4)独立于程序设计语言。用uml建立的软件系统模型可以用Java、vc++、smalltaik等任何一种面向对象的程序设计来实现。

(5)易于掌握使用。uml图形结构清晰，建模简洁明了，容易掌握使用。 使用uml进行系统分析和设计，可以加速开发进程，提高代码质量，支持动态

的业务需求。uml适用于各种规模的系统开发。能促进软件复用，方便地集成已有的系统，并能有效处理开发中的各种风险。

而且uml是一种功能强大的、面向对象的可视化系统分析的建模语言，它采用一整套成熟的建模技术，广泛地适用于各个应用领域。它的各个模型可以帮助开发人员更好地理解业务流程，建立更可靠、更完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理解，以减少语义差异，保障分析的正确性。

通过对学籍管理系统的开发可以看到，uml作为软件工程中的建模语言，代表了面向对象方法的软件开发技术的发展方向，具有重大的经济价值和国防价值，并获得了国际上的广泛支持，具有非常好的应用前景。

由于明年需要参加考研，复习很紧张，所以这学期面向对象分析与设计这门课程我并没有深入地去学习，但这无法影响我对UML的喜爱，老师上课很生动，不光在学习上教导我，在生活和做人理念上也对我有所帮助。这篇学习总结写得比较乱，但我都有用心，在以后的学习过程中我会继续努力，再次多谢庄老师的教诲。

第二篇：UML与面向对象分析与设计

实验实践训练体系

适用专业: 计算机科学技术、软件工程

第一部分 课程与实验综述

一.课程简介及实践要求：

《UML与面向对象分析与设计》是以介绍面向对象的统一建模语言UML为主,使学生了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在Rational Rose环境下用UML进行分析和设计的技术。本课程在教学内容方面着重基本理论、基本知识和基本方法，在培养实践能力方面着重设计构思和设计技能的基本训练，熟练的上机操作能力和分析能力。

实验实践训练是UML与面向对象分析与设计教学的重要技能环节。通过实验，使学生加深理解、验证、巩固课堂教学内容，特别是通过设计和综合实验，发挥学生的想象力和创新能力。

二.课程实验目的要求：

通过UML的实验,学生应该: 1.学会用面向对象的思想去分析和设计相关系统; 2.学会用Rose建模工具进行软件建模。 三.课程实验参考资料

1.(美)Joseph Schmuller著.UML基础、案例与应用.人民邮电出版社,2004 2.(美)Hans-Erik Eriksson.UML 2工具箱. 电子工业出版社,2004 3.吴际,金茂忠.UML面向对象分析.北京航空航天大学出版社,2002 4.赵从军.UML设计及应用.机械工业出版社,2004 5.Grady Booch,James Rumbaugh,Ivar Jacobson.UML用户指南.机械工业出版社,2001 6.吴建,郑潮,汪杰.UML基础与Rose建模案例.人民邮电出版社,2004 第二部分 实验实践指导

实验一

用例图

一、实验目的

1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法

二、实验器材

1. 计算机一台;

2. Rational Rose 工具软件;

三、实验内容

画出ATM系统的用例图

四、实验步骤

1.分析

ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。 通过分析可找出如下几个参与者： 1.ATM 2.客户

通过分析得到如下用例：

(1)存款 (2)取款 (3)查询余额 (4)转帐 (5)修改密码 (6)打印收据 2.绘图步骤：

下面介绍在Rose2003中创建用例图的过程：

(1)在“Use Case View“中双击Main图，或者右击“Use Case View“，弹出在快捷菜单中选择“New”->“UseCase Diagram”，双击图标，出现图1，为编辑用例图做好准备。

(2)在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。

图2 (3)同样的方法添加参与者“ATM”,如图3所示。

图3 (4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。

图4 (5)添加参与者和用例间的关联关系，如图5所示。

图5

五、实验报告要求

1. 整理实验结果。 2. 小结实验心得体会。

实验二

交互图

一、实验目的

1.学会用协作图实现用例

2.掌握顺序图的绘制方法以及顺序图和协作图的相互转换。

二、实验器材

1. 计算机一台;

2. Rational Rose 工具软件;

三、实验内容

画出ATM取款的顺序图，并转换为协作图。

四、实验步骤

1.分析

ATM取款的场景：

(1)通过读卡机，用户插入ATM卡;

(2)ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号;

(3)用户输入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证; (4)用户输入取款数量;

(5)ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息; (6)ATM系统输出先进、ATM卡和显示帐户余额的收据; (7)ATM系统记录事务到日志文件。 寻找场景中的对象：ATM、客户和帐户。 2.绘图步骤：

下面介绍在Rose2003中创建顺序图的过程：

(1)在“Logical View”中新建“Sequence Diagram“，双击图标，出现图1，为编辑顺序图做好准备。

(2)在顺序图编辑窗口中，从工具栏中选择Object图标，在右边的绘图区中添加一个新元素，并取名Customer表明新增一个对象，如图2所示。

图2

(3)同样的方法，添加ATM对象和Account对象，如图3所示。

图3 (4)根据ATM取款的场景，获得第一条消息为“客户向ATM机提交取款需求”，向图中添加消息，如图4所示。

图4

(5)同样的方法添加其它消息，如图5所示。

图5 (6)根据顺序图生成协作图， 步骤如下：“Browse”->“Create Collaboration Diagram”，生成的协作图，如图6所示。

图6

五、实验报告要求

1. 整理实验结果。 2. 小结实验心得体会。

实验三 类图

一、实验目的

1.理解类的基本概念 2.理解类间的关系 3.掌握类图的绘制方法

二、实验器材

1. 计算机一台;

2. Rational Rose 工具软件;

三、实验内容

分析选课系统中的类及关系，然后画出它们的类图。

四、实验步骤

1.分析

在选课系统中，通过分析可抽象出如下几个类： 1.学生类 2.管理员类 3.课程类

学生类和管理员类的属性较容易分析，这里只列出课程类的属性和方法： (1)课程名称 (2)开课教室 (3)课程号 (4)授课教师 (5)选课的学生 (6)开课起始时间 (7)允许选课的学生人数 (8)设置课程号 (9)设置课程名称 (10)查询课程号

(11)查询允许选课的学生人数 2.绘图步骤：

下面介绍在Rose2003中创建类和它们之间关系的过程：

(1)在“Logical View“中双击Main图，或者右击“Logical View“，弹出在快捷菜单中选择“New”->“Class Diagram”，双击图标，出现图1，为编辑类图做好准备。

图1

(2)在逻辑视图中，从工具栏中选择class图标，在右边的绘图区中添加一个新元素，并取名Student表明新增一个类。

图2

(3)选择新创建的元素，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图3对话框。

(4)在对话框中，可以修改元素的名称，这里新元素的名称定为“Student”，如图4所示。

图3

图4 (5)点击“Attributes”选项卡，添加属性，如图5所示。

图5 (6)点击“operations”选项卡，添加方法如图6所示。

图6 (7)同样的方法添加Course类，如图7所示。

图7 (8)创建两个类之间的关系，通过分析得出：学生类和课程类之间为单向关联。 选择图标栏的“关联”，由学生类指向课程类。如图8所示。

图8 (9)创建关联名。右击关联，选择“open specification“，键入关联名，如图9所示。

图9 (10)分别在“Role A Detail“和“Role B Detail“选项卡中键入名称和多重性，如图10所示。

图10 (11)重复(2)-(10)中的步骤完成选课系统整个类图的创建。

五、实验报告要求

1. 整理实验结果。 2. 小结实验心得体会。 实验四 状态图和活动图

一、实验目的

1. 熟悉状态图和活动图的基本功能和使用方法。 2. 掌握如何使用建模工具绘制状态图和活动图方法。

二、实验器材

1. 计算机一台;

2. Rational Rose 工具软件;

三、实验内容

(1)分析图书管理系统中的书和借书证的状态，画出它们的状态图; (2)分析管理员的活动状态，画出管理员的活动图。。

四、实验步骤

1.分析

在图书管理系统中，分析书的状态如下： 1.可借 2.被借 3.被预约 4.删除

借书证的状态如下： 1.可用 2.不可用 3.删除

管理员的活动如下： 1. 处理还书 2. 处理借书 3. 处理罚款 读者的活动如下： 1.登录 2.找书 3.预约 4.浏览 2.绘图步骤：

下面介绍在Rose2003中创建类和它们之间关系的过程：

(1)在“Logical View“中信件“StateChart Diagram”，双击图标，出现图1，为编辑状态图做好准备。

图1 (2)在工具栏中选择“Start State”图标添加到编辑窗口中，如图2所示。

图2 (3)在工具栏中选择“State”图标，添加一个元素，命名为“New book”，如图3所示。

图3

(4)同样的方法添加其它状态，如图4所示。

图4

(5)书的各个状态之间添加转移及相应的事件，如图5所示。

图5

(6)同样的方法得借书证的状态图，如图6所示。

图6

(7)在Rose2003中，绘制图书管理员的活动图，新建“Activity Diagram”，如图7所示：

图7

(8)读者的活动图如图8所示：

图8

五、实验报告要求

1. 整理实验结果。 2. 小结实验心得体会。

第三篇：石河子大学 信息学院 面向对象的设计与分析 OOAD考试总结

OOAD总复习

第一章

1、什么是分析与设计?

1、分析强调对问题和需求的调查研究

2、设计强调的是满足需求的概念上的解决方案

2、什么是面向对象分析与设计?

1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象(或概念)

2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。

3、简单示例：

1、定义用例(use case)

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型(domain model)

面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。(也被称为概念领域模型—conceptual object model)

3、定义交互图

关注的是软件对象的定义—它们的职责和协作。顺序图(sequence diagram)是描述协作的常见方法。它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图

除了在交互图中显示对象协作的动态视图外，还可以用设计类图(design class diagram)来有效的表示类定义的静态视图。这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类

要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章

1、什么是UML?

统一建模语言(UML)是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构(Model Driven Architecture, MDA)CASE工具供应商具有影响。开发者并不需要对其进行学习。

2、三种UML应用方式

1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。用于：①逆向工程;②代码生成。

3、UML作为编程语言—用UML完成软件系统可执行规格说明。

3、什么是UP?

软件开发过程(software development process)描述了构造、部署以及维护软件的方式。统一过程(UP)已经成为一种流行的构造面向对象系统的迭代软件开发过程。

4、迭代(iterative)、进化(evolutionary)和敏捷(agile)

1、迭代开发是UP和大多数其他现代方法中的关键实践。每次迭代都具有各自的需求分析、设计、实现和测试活动。

2、迭代进化开发

小步骤、快速反馈和调整是迭代开发的重要思想。短时迭代为上。迭代的一个关键时光可见

第 1 页

2013-3-31 OOAD总复习

思想是时间定量，或者时长固定。

3、瀑布生命周期

在瀑布(或顺序)生命周期过程中，试图在编程之前(详细)定义所有或大部分需求。而且通常于编程之前创建出完整的设计(或模型集)。

4、什么是敏捷模型?

1、采用敏捷方法并不意味着不进行任何建模，这是错误理解。

2、建模和模型的目的主要用于理解和沟通，而不是构建文档

3、不要对所有或大多数软件建模或者应用UML。

4、尽可能使用最简单的工具。

5、UP所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。

6、UP的四个阶段：初始(inc)、细化(elaboration)、构造(construction)、移交(transition)

第五章

1、进化式需求

1、需求就是系统(广义的说法是项目)必须提供的能力和必须遵从的条件。

2、需求分析的最大挑战是寻找、沟通和记住(通常是指记录)什么事真正需要的，并能够清楚的讲解给客户和开发团队的成员。

3、需求变更是不可避免的，因此有效的管理和关键

4、进化式需求VS瀑布式需求：„„

5、需求按照“FURPS+”模型进行分类：

1、功能性：特性、功能、安全

2、可用性：人性化因素、帮助、文档

3、可靠性：故障频率、可恢复性、可预测性

4、性能：响应时间、吞吐量、准确性、有效性、资源利用率

5、可支持性：适应性、可维护性、国际化、可配置性

6、一些次要因素：实现、接口、操作、包装、授权

6、UP制品如何组织需求：

1、用例模型：一组使用系统的典型场景。

2、补充性规格说明：基本上是用例之外的所有内容。

3、词汇表：词汇表以最简单的形式定义重要的术语。

4、设想：概括了高阶需求，项目的业务案例。

5、业务规划(领域规划)：通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或者业务所要求的，并且许多应用应该遵从这些规则。

第六章

1、用例是文本文档，而非图形;用例建模主要是编写文本的活动，而非制图。

2、用例常用的三种形式：

1、摘要(brief)：简洁的一段式概要，主要用于主成功场景。

2、非正式(casual)：非正式的段落格式。

3、详述(fully-dressed)：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和保证成功。

3、参与者(actor)、场景(scenario)、用例(use-case)

1、参与者是某些具有行为的事物，可以是人、计算机系统或者组织。

2、场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例

时光可见

第 2 页

2013-3-31 OOAD总复习

3、用例是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

4、准则：如何发现用例?

1、选择系统边界

2、辨别主要参与者

3、辨别每个参与者的目标

4、定义用例以满足目标

5、准则：什么样的测试有助于发现有用的用例?

1、老板测试(the boss test)：老板的一问一答

2、EBP测试(the ERP test)基本业务过程

3、规模测试(the size test)

6、示范：应用上述测试

1、就供应者合同进行协商：

比ERP更广泛，用时更长。更适合作为业务用例，而非系统用例。

2、处理退货

能够通过老板测试。看上去与ERP类似。规模适合

3、登陆

如果你一整天都在登陆，老板不会满意

4、在游戏板上移动棋子

单一步骤，不能通过规模测试

第八章

1、迭代1的需求和重点：OOA/D技术的核心

2、过程：初始(inception)和细化(elaboration)

初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。

细化是一般项目中最初的一些列迭代，其中包括：

1、对核心、有风险的软件架构进行编程和测试

2、发现并稳定需求的主要成分

3、规避主要风险

第九章

1、领域模型是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念膜性能高、领域对象模型和分析对象模型。

2、应用UML表示法，领域模型被描述为一组没有定义操作(方法的特征标记)的类图(class diagram)：

1、领域对象或者概念类

2、概念类之间的关联

3、概念类的属性

3、准则：如何创建领域模型?

1、寻找概念类

2、将其绘制成UML类图中的类

3、添加关联和属性

4、准则：如何找到概念类?

时光可见

第 3 页

2013-3-31 OOAD总复习

1、重用和修改现有的模型

2、使用分类列表

3、确定名词短语

5、准则：何时需要描述类?

1、需要有关商品或者服务的描述，独立于任何商品或服务的现有实例

2、删除其所描述事物的实例后，导致信息丢失，而这些信息也是需要维护的，但是被错误地与所删除的事物关联起来

3、减少冗余或重复信息

6、关联(association)是类(更精确的说，是这些类之间的实例)之间的关系，表示有意义和值得关注的连接

7、准则：在UML中如何对关联命名?

以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读和有意义的顺序。

8、准则：任何属性都不表示外键

第十章

1、系统顺序图(SSD)是为阐述与讨论系统相关的输入和输出事件而快速、简单地创建制品。它们是操作契约和(最重要的)对象设计的输入

2、SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。

3、对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统(作为黑盒)以及由参与者发起的系统事件。

4、什么是系统顺序图?

系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之间的事件，所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。

第十一章

1、操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。

2、定义：契约有哪些部分?

1、操作：操作的名称和参数

2、交叉引用：会发生此操作的用例

3、前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。

4、后置条件：最重要的部分。完成操作后，领域模型对象的状态。

3、什么是系统操作?

系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。

4、后置条件描述了领域模型内对象状态变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。

5、准则：契约在何时有效?

在UP中，用例是项目需求的主要知识库。用例可以为设计提供大部分或全部所需细节。这中情况下，契约就没什么用处。

6、准则：如何创建和编写契约?

1、从SSD图中确定系统操作

时光可见

第 4 页

2013-3-31 OOAD总复习

2、如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约

3、使用以下几种类表来描述后置条件：

1、创建或删除实例

2、属性值的变化

3、形成或消除关联(UML连接)

第十三章

1、什么是逻辑架构和层?

逻辑架构是软件类的宏观组织结构，它将软件类组织为包(或命名空间)、子系统和层等。之所以称之为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理计算机上对这些元素进行部署。

层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。

OO系统中通常包括的层有：

1、用户界面

2、应用逻辑和领域对象

3、技术服务

2、什么是软件架构?

架构是一组重要的决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。

第十五章

1、交互图这一术语是对以下两种更为特化的UML图的统称

1、顺序图：以一种栅栏格式描述交互，其中在右侧添加新创建的对象。

2、通信图：以图或者网络格式描述对象交互，其中对象可以置于图中的任何位置。

2、顺序图的基本表示法：

1、消息：实心箭头

2、应答或返回：在活动条末端使用应答(或返回)消息线

3、异步调用：虚线

3、通信图的基本表示法：

1、链是连接两个对象的路径，它指明了对象间某种可能的导航和可见性。链是关联的实例。

2、消息：对象间的每个消息都可以使用消息表达式和指明消息方向的小箭头表示。

3、消息的顺序编号：

1、不为第一个消息编号

2、使用合法编号方案来表示后续消息的顺序和嵌套，其中的嵌套消息要使用附加的数字

4、可以在顺序编号后使用带有方括号[]的条件句子来表示有条件消息。为真时发送消息

5、互斥的有条件路径：在顺序编号后面加上字母，第一个字母是a

6、迭代或循环：在顺序编号后面加*

第十六章

时光可见

第 5 页

2013-3-31 OOAD总复习

1、表示UML属性的方法：属性文本和关联线

2、在DCD中使用关联表示属性时的风格：导航性箭头、角色名、

3、对于领域模型使用类图的时候，需要表示关联名称，但是要避免使用导航箭头，因为领域模型不是软件透视图。

3、对数据类型对象使用属性文本表示法，对其他对象使用关联线。

4、依赖用从客户到提供者的虚线箭头表示(AB，B发生变化会影响A)

5、比较常见的依赖类型：

1、拥有提供者类型的属性

2、向提供者发送消息

3、接收提供者类型的参数

4、提供者是超类或者接口

6、依赖标签

7、插座法表示接口

8、限定关联

第十七章

1、GRASP：基本OO设计的系统方法

2、GRASP：使用职责进行OO设计的学习工具

3、RDD(responsibility-driven design)：职责驱动设计。

4、UML把职责定义为“类元的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：行为和认知。

1、行为职责：

1、自身执行一些行为，如创建对象或计算。

2、初始化其他对象中的动作

3、控制和协调其他对象中的活动

2、认知职责：

1、对私有封装数据的认知

2、对相关对象的认知

3、对其能够导出或计算的事物的认知

5、对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。

6、职责的粒度会影响职责到类和方法的转换。

7、什么是模式?

如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。

在OO设计中，模式是对问题和解决方案的已命名描述，它可以用于新的语境。

8、使用GRASP进行对象设计的简短示例

1、创建者

2、信息专家

3、低耦合

4、控制器

5、高内聚

9、创建者：谁创建了A?

解决方案：(有一个为真即可)

时光可见

第 6 页

2013-3-31 OOAD总复习

1、B“包含”或组成聚集了A

2、B记录A

3、B紧密地使用A

4、B具有A的初始化数据

10、信息专家：如果给定键值，谁知道Square对象的信息?

解决方案：把职责分配给具有完成该职责所需信息的那个类

11、低耦合：为什么是Board而不是Dog?如何减少变化产生的影响?

解决方案：分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估

12、控制器：在UI层之上首先接受和协调系统操作的对象是什么?

解决方案：把职责分配给能代表下列选择之一的对象：

1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统

2、代表发生系统操作的用例场景(用例或会话)

13、高内聚：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用?

解决方案：职责分配应保持高内聚，依此来评估备选方案

第十八章

1、用例实现描述某个用例基于协作对象如何在设计模型中实现。更精确的说，设计者能够描述用例的一个或多个场景的设计，其中的每一个设计都称为用例实现。

2、下面说明了一些制品之间的关系：

1、用例指出了SSD中所示的系统操作

2、系统操作可以称为输入到领域层交互图的控制器中的起始消息

3、领域层交互图阐述了对象如何交互完成所需任务—用例实现

第十九章

1、可见性是一个对象看见其他对象或引用其他对象的能力

2、实现对象A到对象B的可见性通常有四种方式：

1、属性可见性—B是A的属性

2、参数可见性—B是A中方法的参数

3、局部可见性—B是A中方法的局部对象(不是参数)

4、全局可见性—B具有某种方法的全局可见性

第二十章

1、用OO语言(java或者C#)创建代码并不是OOA/D的一部分，它是最重的目标

2、在UP中具有实现模型。源代码、数据库定义、JSP/XML/HTML页面等都是实现制品

3、面向对象语言中的实现需要以下元素编写源代码：

1、类和接口的定义

2、方法的定义

第二十三章

1、在迭代1结束的时候，应该已经完成以下任务：

1、所有软件都已经被充分地测试

2、客户定期地参与对已完成部分的评估

3、已经对系统进行了完成的集成和固化，使其成为基线化的内部版本

2、迭代2的需求和重点：对象设计和模式

时光可见

第 7 页

2013-3-31 OOAD总复习

1、支持第三方外部服务的变化

2、复杂的定价规则

3、需要进行设计，使得在销售总额变化时刷新GUI窗口

第二十五章

1、之前介绍了5个GRASP模式：信息专家、创建者、高内聚、低耦合、控制器

2、下面介绍最后4个GRASP模式：多态、间接性、纯虚构、防止变异

3、多态：如何处理基于类型的选择?如何创建可插拔的软件构件?

解决方案：当相关选择或行为随类型(类)有所不同时，使用多态操作作为变化的行为类型分配职责。推论：不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择

4、纯虚构：当你并不想违背高内聚和低耦合或者其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责?

解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念—虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的。

5、间接性：为了避免两个或多个事物之间直接耦合，应该如何分配职责?如何使用对象解耦合，以支持低耦合并提高复用性潜力?

解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性

6、防止变异：如何设计对象、子系统和系统，使其内部的变化或不稳定不会对其他元素产生不良影响?

解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口

第二十六章

1、适配器(GoF)：如何解决不相容的借口问题，或者如何为具有不同接口的类似构件提供稳定的借口?

解决方案：通过中介适配器对象，将构件的原有接口转换为其他接口。增加一层间接性对象，通过这些对象将不同的外部接口调整为在应用程序内使用的一致接口

2、工厂：当有特殊考虑(例如存在复杂创建逻辑，为了改良内聚而分离创建职责等)时，应该由谁来负责创建对象?

解决方案：创建称为工厂的纯虚构对象来处理这些创建职责

3、单实例类：只有唯一实例的类即为“单实例类”。对象需要全局可见性和单点访问

解决方案：对类定义静态方法用以返回单实例

4、策略：如何设计变化但相关的算法或政策?如何设计才能使这些算法或政策具有可变更能力?

解决方案：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同接口

5、组合：如何能够像处理非组织(原子)对象一样，(多态地)处理一组对象或具有组合解耦股的对象呢?

解决方案：定义组合和原子对象的类，使它们实现相同的接口

6、外观：对一组完全不同的实现或接口需要公共、统一的接口。可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变，怎么办?

解决方案：对子系统定义惟一的接触点—使用外观对象封装子系统。该外观对象提供了惟一和统一的接口，并负责与子系统构件进行协作

7、观察者(发布—订阅)：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并时光可见

第 8 页

2013-3-31 OOAD总复习

且想要在发布者产生事件时以自己独特的方式作出反应。此外，发布者想要保持与订阅者的低耦合。如何对此进行设计呢?

解决方案：定义“订阅者”和“监听器”接口。订阅者实现此接口。发布者可以动态注册关注某事件的订阅者，并在事件发生时通知它们

第三十章

1、包含关系：多个用例中存在部分相同的行为，这是常见的现象

2、如下情形可以分解出子功能用例并使用包含关系：

1、用例在其他用例中重复使用

2、用例非常复杂并冗长，将其分解为子单元便于理解

3、具体用例是由参与者发起，完成了参与者所期望的完整行为。它们通常是基本业务过程用例

4、抽象用例永远不能被自己实例化，它是其他用例的子功能用例

5、包含其他用例的用例，或者是被其他用例扩展或者泛化的用例被称为基础用例

6、被其他用例包含的用例，或者扩展、泛化其他用例的用例被称为附加用例

7、扩展关系的思路是，创建扩展或附加用例，并且在其中描述：在何处何何种条件下该用例扩展某基础用例的行为

8、事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系

9、扩展关系的UML表示法：

1、扩展用例指向基础用例

2、在线上可以表示条件和扩展点

第三十一章

1、泛化是在多个概念中识别共性和定义超类(普通概念)与子类(具体概念)关系的活动

2、概念超类与子类之间是什么关系?

3、概念超类的定义较子类的定义更为概括或包含范围更广

4、泛化和类集的关系：概念子类集合的所有成员都是其超类集合的成员

5、100%规则：概念超类的定义必须100%适用于子类，子类必须100%与超类一致：属性、关联

6、Is-a规则：子类集合的所有成员必须是其超类集合的成员

7、什么是正确的概念子类?

潜在的子类应该遵守下述规则：

1、100%规则(定义的一致性)

2、Is-a规则(集合成员关系的一致性)

8、在下述几种情形下创建概念类的子类

1、子类有额外的有意义的属性

2、子类有额外的有意义的关联

3、子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方式是我们所关注的

4、子类概念表示了一个活动体(例如动物、机器人等)，其行为与超类或者其他子类不同，而这些行为是我们所关注的

9、在下述情形下可以创建与子类具有泛化关系的超类

1、潜在的概念子类表示的是相似概念的不同变体

2、子类满足100%和Is-a规则

时光可见

第 9 页

2013-3-31 OOAD总复习

3、所有子类都具有相同的属性，可以将其解析出来并在超类中表达

4、所有子类都具有相同的关联，可以将其解析出来并与超类关联

10、在领域模型中，如果类C可能同时有多个相同的属性A，则不要将属性A置于C至中，应该将属性A放在另一个类中，并且将其与C关联

11、在领域模型中增加关联类的可能线索有：

1、有某个属性与关联有关

2、关联类的实例具有依赖于关联的生命期

3、两个概念之间有多对多关联，并且存在于关联自身相关的信息

12、在下述情况下，可以考虑组合关系：

1、部分的生命期在组成生命期界限之内，部分的创建和删除依赖于整体

2、在物理或逻辑组装上，整体—部分关系很明确

3、组成的某些属性会传递给部分

4、对组成的操作可能传递给部分

13、在关联中可能会

时光可见 第 10 页 2013-3-31

第四篇：面向对象分析与设计-牙科诊所管理系统

牙科诊所管理系统

王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。

当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。

系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。

1、建立牙科诊所管理系统的对象模型。

2、建立牙科诊所管理系统的用例模型。

3、用数据流图建立所述牙科诊所管理系统的功能模型。

4、画出牙科诊所管理系统的状态图。

1、建立牙科诊所管理系统的对象模型

(1)词法分析，找出(名词)作为对象的候选者;

王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。

当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。

系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。

(2)找出问题域中对象，对候选对象进行严格筛选，从中删除不正确的或不必要的，只保留确实应该记录其信息或需要提供服务的那些对象。

王大夫(牙医的实例)

小镇(牙科诊所的地址属性)

牙科诊所

牙科助手 牙科保健员 接待员(外部角色，不是问题域内的对象)

软件系统(与“系统”同义，指将来开发的软件产品)

预约

病人

预约登记表 就诊时间(与“预约时间”，“约定时间”同义，都是“预约登记表”的属性)

预约时间 约定时间 系统

名字(与“姓名”同义，是病人记录的属性)

记录的病人数据(即“病人记录”)

病历号(病人记录的属性)

姓名

日期(“预约登记表”的属性)

预约信息(与“病人清单”包含的信息基本相同)

病人清单

病人记录

电话号码(病人记录的属性)

每天工作安排 每周工作安排

(3)确定问题域中对象彼此之间的关系。

1牙科诊所11..*病人清单1..*1预约登记表111..*工作安排1..**预约11病人记录1病人1..*每天工作安排每周工作安排

2、建立牙科诊所管理系统的用例模型。

牙科诊所管理系统<>完成预约*1111*查询预约*职员*更新预约<><>取消预约<>1*牙医1打印工作安排访问预约登记表<><>访问病人记录*

3、用数据流图建立所述牙科诊所管理系统的功能模型。

1查询病人数据病人数据病人数据D1病人记录姓名病人日期2查询预约日期有效日期3完成预约预约信息7打印工作安排每天和每周工作安排牙医4取消预约姓名/日期预约信息预约信息预约信息预约信息职员姓名5更新预约D2预约登记表预约信息姓名/日期6查询预约预约信息职员

4、画出牙科诊所管理系统的状态图。

牙科诊所管理系统的主要功能是实现病人预约，状态图如下，图中把除了完成病人预约之外的事务笼统地称为日常事务。

查找病人记录及可能的预约输入有效名字开始返回确认信息处理日常事务退出进行预约确认预约输入非法名字、按姓名或日期查询，打印工作安排，取消预约

第五篇：PHP中面向对象设计的经验总结

你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起 。 ----- Arthur J.Riel

1. 所有数据都应该隐藏在所在的类的内部。

2. 类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 3. 尽量减少类的协议中的消息。

4. 实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。

5. 不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 6. 不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。

7. 类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。

8. 类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响。 9. 把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

10. 把不相关的信息放在另一个类中(也即：互不沟通的行为)。朝着稳定的方向进行依赖。 11. 确保你为之建模的抽象概念是类，而不只是对象扮演的角色。

12. 在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。 13. 在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。

14. 对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。

15. 对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

16.在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。

17. 尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则)。

18. 从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。 19. 去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

20. 不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是

否应当迁移到已经存在或者尚未发现的某个类中。

21. 我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。

22. 尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。 23. 尽量减少类和协作者之间传递的消息的数量。

24. 尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。 25. 尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。 26. 如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。

27. 类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

28. 类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

29. 让系统功能在窄而深的继承体系中垂直分布。

30. 在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在

构造函数中实现，但不是必须如此。 31. 在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。

32. 约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。 33. 约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。 34. 类必须知道它包含什么，但是不能知道谁包含它。

35. 共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。 36. 继承只应被用来为特化层次结构建模。

37. 派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。

38. 基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

39. 在理论上，继承层次体系应当深一点，越深越好。

40. 在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

41. 所有的抽象类都应当是基类。 42. 所有的基类都应当是抽象类。

43. 把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。

44. 如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。

45. 如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。

46. 如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。

47. 对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。

48. 对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。

49. 不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。

50. 不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

51. 如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。

52. 在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。 53. 不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。 54. 在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。

55. 如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。 56. 只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型?(2)基类是不是派生类的一部分?

57. 如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。

58. 在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。 59. 不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。 60. 面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 61. 不要绕开公共接口去修改对象的状态。