面向对象参考答案整理

客观世界是由对象组成，任何客观实体都是对象，复杂对象可以由简单对象组成。

具有相同属性和操作的对象可归纳成类，对象是类的一个实例。

类可以派生出子类，子类除了继承父类的全部特性外还可以有自己的特性。

对象之间的联系通过消息传递来维系。

封装是面向对象方法的一个重要原则，封装有两个含义：结合性即将属性和方法结合；信息隐蔽性利用接口机制隐蔽内部细节。

继承性是指子类可以自动拥有父类的全部属性与操作的机制。

继承可分为单重继承和多重继承两类。

继承简化了对现实世界的描述定义子类时不必定义那些在父类中已经定义过的属性和操作使软件的复用性提高。

多态性是指同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。

2 什么是分解、耦合度和内聚度？耦合度是从模块外部考察模块的独立性程度。

模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。

模块间耦合高低取决于模块接口的复杂性、调用的方式及传递的消息。

内聚度（Cohesion）是模块内部各成份（语句或语句段）之间的联系。

模块内部各成份联系越紧，即其内聚度越大，模块独立性就越强。

分解：将系统分为更小成分3 什么是动态绑定？动态绑定，是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。

4 什么是用例图，用例图有哪些部分组成。

用例是从用户的观点对系统行为的一个描述,特定的环璄下,特定的目标相关的系统与用户之间的一组可能的交互序列组成.用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。

用例图包含6个元素：参与者（Actor）、用例（Use Case）、关联关系（Association）包含关系（Include）、扩展关系（Extend）、泛化关系（Generalization）5 用例图中参与者之间的关系有哪些？用例之间的关系有哪些？参与者之间的关系：泛化关系用例之间的关系：关联关系、包含关系、扩展关系、泛化关系地位：用例图显示了用例和活动者之间、用例之间、以及活动者之间的关系，这种关系描述了模型元素之间的语义联系。

其源于客户需求分析，又称用例分析，是整个系统开发中的非常关键的过程。

作用：用例图是使用统一建模语言设计新系统的起点，在初始阶段完成。

用例图提供了系统的一个概览，为系统提供给用户的功能进行说明。

从形式上讲，用例记录用户使用系统时从头到尾的一系列事件。

是用户和开发者一起深入剖析系统功能的起点。

在开发项目的初期，用例图可以描述现实世界中的活动和动机。

同时可以在项目后期改进用例图以反映用户界面和设计细节。

参与者获取方法谁使用系统的主要功能谁需要系统支持他们的主要工作谁来维护、管理系统使其能正常工作系统需要控制哪些硬件系统需要与哪些系统交互对系统产生的结果感兴趣的是哪些人或哪些事物用例获取方法: 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。

参与者要求系统提供哪些功能参与者需要读、产生、删除、修改或存储系统中的信息有哪些类型必须提醒参与者的系统事件有哪些参与者必须提醒系统事件有哪些8 用例之间的扩展、泛化、包含三种关系有什么异同，请分别举例说明。

扩展关系扩展用例被定义为基础用例的增量扩展。

n 基础用例提供扩展点以添加新的行为。

n 扩展用例提供插入片段以插入到基础用例的扩展点上泛化关系父用例也可以被特别列举为一个或多个子用例。

n 子用例表示父用例的特殊形式。

n 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为包含关系客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。

9 类图有哪些元素构成？类之间的关系有哪些？掌握UML中类图的绘制方法。

类、接口、协作、依赖关系、泛化关系、关联关系、实现关系类之间的关系：依赖关系、泛化关系、关联关系、实现关系10 简述类的聚合和组合关系的异同点。

聚合是一种特殊的关联, 聚合更明确指出聚合的主体具有整体-部分关系.组合是一种特殊的聚合, 组合中的某个主体控制着另外一个主体的生命周期,而且他们还存在整体-部分关系.聚合和组合的主要区别在于聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。

组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

11 对象图的适用场景以及它的优缺点。

对象图适用于论证类模型的设计以及对源代码进行分析和说明。

其优点是能够直观理解出系统运行时的实时状态，缺点是比较复杂，工作量大。

12 掌握交互图（时序图与协作图）的绘制方法。

●交互图用来一步一步地描述用例地实现流程，包括流中需要什么对象，对象之间发送什么，什么角色启动流、消息按什么顺序发送等。

●交互图通过从用例建模中得到的用例文档说明、词汇表和用例图来创建。

如何创建交互图创建交互图的步骤如下：1.寻找对象2.寻找角色3 获取消息，并加入图中。

13 掌握活动图、状态图的绘制方法。

活动图绘制方法：●第一步，定义活动图的范围首先应该定义您要对什么建模。

单个用户案例？一个用户案例的一部分？一个包含多个用户案例的商务流程？一个类的单个方法？一旦您定义了所作图的范围，应该在其顶部，用一个标注添加标签，指明该图的标题和唯一的标示符。

您有可能也想要包括该图的时间甚至作者名。

●第二步，添加起始和结束点每个活动图有一个起始点和结束点，因此您也要马上添加它们。

在《UML精粹》(UML Distilled)(参见参考资料)，Fowler 和 Scott认为结束点是可选的。

有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是到一个结束点也是无害的。

这样，当其他人阅读您的图时，他或她知道您已经考虑了如何退出这些活动。

●第三步，添加活动如果您正对一个用户案例建模，对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤，加上对起始步骤系统响应的任何步骤)。

如果您正对一个高层的商务流程建模，对每个主要流程引入一个活动，通常为一个用户案例或用户案例包。

最后，如果您正对一个方法建模，那么对此引入一个活动是很常见的。

●第四步，添加活动间的转变我的风格总是应该退出一个活动，即使它是转变到一个结束点。

一旦一个活动有多个转变时，您必需对每个转变加以相应标示。

●第五步，添加决策点有时候，您所建模的逻辑需要做出一个决策。

有可能是需要检查某些事务或比较某些事务。

要注意的是，使用决策点是可选的。

例如，在图 1中，我可以只是简单地将“接受”和“拒绝”两个转变直接接到“在大学报名(Enrollin University)”活动。

"●第六步，找出可并行活动之处当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。

在图 1中，您看到是有可能“参加简要介绍(attendoverview)”和“报名研讨班(enroll in seminars)”可以按任意次序进行，但是它们都得在您结束整个流程前完成。

状态图建模技术建模步骤：找出适合用模型描述其行为的类。

确定对象可能存在的状态。

确定引起状态转换的事件。

确定转换进行时对象执行的相应动作。

对建模的结果进行相应的精化和细化。

①单一职责原则(SRP)含义：就一个类而言，应该仅有一个引起它变化的原因。

②开放——封闭原则(OCP)含义：软件实体应该是可以扩展的，但是不可修改的；对于扩展是开放的，对于修改是封闭的。

③Liskov替换原则(LSP)含义：子类型必须能够替换掉它们的基类型。

④依赖倒置原则(DIP)含义：高层模块不应依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。

⑤接口隔离原则(DIP)含义：不应该强迫客户依赖于它们不用的方法。

接口属于客户，不属于它所在的类层次结构。

15 包图与组件图的概念，掌握包图的设计原则，包括稳定性和抽象度的衡量方法。

包图：对于庞大的应用系统而言，其包含的类成百上千，再加上复杂的类间关系，处理复杂度太高。

这也就是引入了“包”这种分组事物构造块。

对语义上相关的元素进行分组；定义模型中的“语义边界”；组件图：描述了软件的各种组件和它们之间的依赖关系。

组件图中通常包含3个元素：组件,接口,依赖关系.包图的设计原则：内聚性原则：重用－发布等价原则（REP）：重用的粒度就是发布的粒度.当一个包的目的是为了重用，那么这个包下的所有类都应该是重用的。

共同重用原则（CRP）：如果重用了包中的一个类，那么就要重用包中的所有类。

共同封闭原则（CCP）：包中的所有类对于同一种性质的变化应该是共同封闭的。

一个变化若对一个封闭的包产生影响，则将对该包中的所有类产生影响，而对于其他包则不造成任何影响。

耦合性原则：无环依赖原则（ADP）：在包的依赖关系图中不允许存在环稳定依赖原则（SDP）：朝着稳定的方向进行依赖稳定抽象原则（SAP）：包的抽象程度应该与其稳定程度一致稳定性度量Ca输入耦合度，依赖于该包内的类的数目；Ce输出耦合度，依赖于该包外的类的数目；不稳定性I=Ce/(Ca+Ce)I=0表示该包具有最大的稳定性；I=1表示该包具有最大的不稳定性。

抽象性度量Nc包中类的总数；Na包中抽象类的数目；抽象性度量A=Na/NcA=0意味着包中没有任何抽象类；A=1意味着包中只包含抽象类。

模式等）策略模式：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

本模式使得算法可独立于使用它的客户而变化。

将这些算法硬编进使用它们的类中是不可取的，其原因如下:需要功能的客户程序如果直接包含算法代码的话将会变得复杂，这使得客户程序庞大并且难以维护, 尤其当其需要支持多种算法时问题会更加严重。

不同的时候需要不同的算法，我们不想支持我们并不使用的算法。

当功能是客户程序的一个难以分割的成分时,增加新的算法或改变现有算法将十分困难。

适用性需要使用一个算法的不同变体。

算法使用客户不应该知道的数据。

可使用策略模式以避免暴露复杂的、与算法相关的数据结构。

一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。

将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

相关实例：收银打折系统观察者模式：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。

适用性当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。

桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

效果采用桥接模式可以获得以下好处。

（1）将接口与实现分离：一个接口可以有若干实现，一个实现也可以为若干对象服务，表示逻辑的对象可以动态地与实现功能的对象组合。