十一 面向对象技术(考点篇)

1  面向对象基础

面向对象的基本概念

(1)对象：由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。

 

(2)类：现实世界中实体的形式化描述，类将该实体的属性(数据)和操作(函数)封装在一起。 对象是类的实例，类是对象的模板 。

类可以分为三种：实体类、接口类(边界类)和控制类。实体类的对象表示现实世界中真实的实体，如人、物等。接口类(边界类)的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条

形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。控制类的对象用来控制活动流，充当协调者。

 

(3)抽象：通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。

 

(4)封装：是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。

面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。

 

(5)继承：表示类之间的层次关系(父类与子类),这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。

 

(6)多态：不同的对象收到同一个消息时产生完全不同的结果。包括参数多态(不同类型参数多种结构类型)、包含多态(父子类型关系)、过载多态(类似于重载，一个名字不同含义)、强制多态(强制类型转换)四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。-- 参数多态（ 方法的参数可以接受不同类型的对象，并根据实际传递的对象类型来执行不同的操作 ）、包含多态（ 同样的操作可用于一个类型及其子类型 ）、过载多态( 同一个名(操作符﹑函数名)在不同的上下文中有不同的类型 )、强制多态（ 强制类型转换 ）

参考： 面向对象设计领域中的参数多态，包含多态，过载多态和强制多态

 

(7)接口：描述对操作规范的说明，其只说明操作应该做什么,并没有定义操作如何做。

 

(8)消息：体现对象间的交互，通过它向目标对象发送操作请求。

 

(9)覆盖：子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。

即在子类中重定义一个与父类同名同参的方法。

 

(10)函数重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。 --同名不同参

 

(11)绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

 

面向对象的分析OOA

是为了确定问题域，理解问题。

包含五个活动：

• 认定对象、
• 组织对象、
• 描述对象间的相互作用、
• 确定对象的操作、
• 定义对象的内部信息。

面向对象需求建模：

用例模型：

1. 识别参与者
2. 合并需求获得用例
3. 细化用例：用例的名字、说明、事件流、非功能需求、前置和后置条件、扩展、优先级
4. 调整用例模型：包含、扩展、泛化

用例模型是面向对象系统设计与分析中的一个重要概念，它 用于对系统的功能以及与系统进行交互的外部事物进行建模。 用例模型表示系统和参与者间的交互，由表示参与者和用例的图以及对每个用例的详细描述组成。这个步骤的主要工作是标识与每个事件相关的用例并生成系统用例图，以及编写基本用例叙述，并不断修改直到获得用户需求的精确描述。用例模型奠定了整个系统软件开发的基础，它是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例模型的使用在 Rational Unified Process（RUP）中被推崇备至， 整个RUP流程都被称作是"用例驱动"的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件。

分析模型：

1. 定义概念类
2. 识别类之间关系:依赖、关联、聚合、组合、泛化、实现。
3. 为类添加职责
4. 建立交互图

类之间关系，参考：UML——类图详解_绘制类图例子

面向对象的分析模型主要关注于问题域的本质，通过抽象化问题域来形成分析模型。这种模型是平台无关的，旨在分析软件整体的外向型行为，提炼软件系统内的核心域知识。面向对象的分析模型强调映射问题域，使得系统中的对象及其关系能够如实地反映问题域中固有的事物及其关系。这种模型采用面向对象的方法来设计数据模型，其中数据以对象为单位进行存储，每个对象包含属性和方法，具有类和继承等特点。面向对象的分析模型不仅应用于软件开发过程，还扩展到数据库系统、交互式界面等多个领域，成为一种贴近自然运行模式的系统建模方法。

面向对象的分析模型通常由三个基本模型组成：

1. 功能模型：表达系统的详细需求，为软件的进一步分析和设计打下基础。它由用例图和场景描述组成，着重于系统内部数据的传送和处理。
2. 对象模型：表示系统的静态结构，包括类和对象、它们的属性和操作以及它们之间的关系。这个模型描述现实世界中实体的对象以及它们之间的关系，表示目标系统的静态数据结构。
3. 动态模型：描述系统的动态结构和对象之间的交互，表示瞬时的、行为化的系统的“控制”特性。它着重于系统的控制逻辑，考察在任何时候对象及其关系的改变，描述这些涉及时序和改变的状态。

这些模型共同作用，帮助开发人员从不同角度理解和分析问题域，从而设计和构建出能够真实反映问题域的对象导向的软件系统。

当然涉及数据模型：数据模型就是E-R模型(E-R图)。

面向对象的设计OOD

是设计分析模型和实现相应源代码，设计问题域的解决方案，与技术相关。OOD 同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。

 

面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；

设计模型则包含以 包图 表示的 软件体系结构图 、以 交互图表示 的 用例实现图 、完整精确的 类图 、针对复杂对象的 状态图 和用以描述流程化处理过程的 活动图 等。

包图表示架构图：包图类似文件夹的符号；交互图是描述对象之间的关系以及对象之间的信息传递的图，它包含了序列图(顺序图)、通信图、定时图、交互概览图；

面向对象的设计原则：

(1)单一责任原则。就一个类而言，应该仅有一个引起它变化的原因。即，当需要修改某个类的时候原因有且只有一个，让一个类只做一种类型责任。

 

(2)开放一封闭原则。软件实体(类、模块、函数等)应该是可以扩展的，即开放的；但是不可修改的，即封闭的。---该开放扩展的开发，该封闭的封闭。

(3)里氏替换原则。子类型必须能够替换掉他们的基类型。即，在任何父类可以出现的地方，都可以用子类的实例来赋值给父类型的引用。

 

(4)依赖倒置原则。抽象不应该依赖于细节，细节应该依赖于抽象。即，高层模块不应该依赖于低层模块，二者都应该依赖于抽象。--底层依赖高层，细节依赖抽象

(5)接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。即：依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。

 

上述(1)～(5)是面向对象方法中的五大原则。除了这五大原则之外，Robert C. Martin提出的 面向对象设计原则还包括以下几个。

 

(6)重用发布等价原则。重用的粒度就是发布的粒度。

(7)共同封闭原则。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

-- 包中所有类访问同级，外界变化对一个包中所有成员有影响，共同进退。

 

(8)共同重用原则。一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

-- 重用了一个，那么包中其他的也重用了，共同重用，同进退。

 

(9)无环依赖原则。在包的依赖关系图中不允许存在环，即包之间的结构必须是一个直接的无环图形。-- 不能成环

 

(10)稳定依赖原则。朝着稳定的方向进行依赖。

 

(11)稳定抽象原则。包的抽象程度应该和其稳定程度一致。

 

面向对象的测试：

一般来说，对面向对象软件的测试可分为下列4 个层次进行。

• (1)算法层。测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。
• (2)类层。测试封装在同一个类中的所有方法与属性之间的相互作用。在向面对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块测试。
• (3)模板层。测试一组协同工作的类之间的相互作用，大体上相当于传统软件测试中的集成测试，但是也有面向对象软件的特点(例如，对象之间通过发送消息相互作用)。
• (4)系统层。把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。

2 UML

UML(统一建模语言):是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。

从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

• (1)构造块。UML有三种基本的构造块，分别是事物(thing)、关系(relationship)和图diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。图 =  事务 + 关系
• (2)公共机制。公共机制是指达到特定目标的公共 UML方法。
• (3)规则。规则是构造块如何放在一起的规定。

2.1    事物

结构事物：模型的静态部分，如类、接口、用例、构件等；--结构部分肯定是静态的

行为事物：模型的动态部分，如交互、活动、状态机；--行为预示着动态

分组事物：模型的组织部分，如包；-- 分组意味着组织架构

注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。--说明

2.2   关系

依赖：一个事物的语义依赖于另一个事物的语义的变化而变化.

关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中 组合事物之间关系更强 。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。

-- 组合是头和眼睛，聚合是公司和个人。

泛化：一般/特殊的关系，子类和父类之间的关系.

实现：一个类元指定了另一个类元保证执行的契约。

关系 UML图形代号如下：

关联一条线，黑菱是组合，白菱是聚合；依赖黑虚；实现白虚；泛化白实。

2.3    图

参考：

UML2.0图，书上是13种，实际还包含制品图，一共14种，了解即可，总分类如下：

总分类

静态图(结构图)：偏向于描述结构及组成的等等。

动态图(行为图)：偏向于描述行为、执行顺序、合作关系等等

交互图：动态图中的顺序图、通信图、定时图、交互概览图这四个组成的

类图

静态图，为系统的静态设计视图， 展现一组对象、接口、协作和它们之间的关系 。

UML类图如下：

系统用类的方式表示，以及他们之间的关系协作。识别类的名字及方法属性等

对象图

静态图，展现 某一时刻一组对象及它们之间的关系，为类图的某一快照 。在没有类图的前提下，对象图就是静态设计视图。如下：

类图的某一个时刻的快照，识别类名字属性等等

用例图

静态图，展现了 一组用例、参与者以及它们之间的关系 。用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。

如下：

用例(即操作)、参与者及他们之间的关系，识别参与者，及扩展、包含、泛化字眼的关系。

扩展是可做可不做，如上图的查询书籍信息，修改书籍信息可查可不查；包含是要想做A，必须先做B，如上图登记外界信息必须先登录。

序列图/顺序图

即顺序图，动态图，是 场景的图形化表示 ，描述了 以时间顺序组织的对象之间的交互活动 。有同步消息(进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示),异步消息(发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示)、返回消息(由从右到左的虚线箭头表示)三种。如下：

上方的对象对应下方箭头上的的成员和方法。

场景的图形化表示，以时间顺序组织的对象间交互活动。识别三种消息：同步(实心三角箭头)、异步(空心箭头)、返回(虚线箭头)。

另外它是交互图之一。

识别根据消息类型以及垂直长条

通信图/协作图

动态图，即协作图， 强调参加交互的对象的组织 。如下：

强调的是发送和接收消息的对象之间的组织结构。

使用协作图来说明系统的动态情况。

协作图使描述复杂的程序逻辑或多个平行事务变得容易。

如果需要强调时间和序列，最好选择序列图；如果需要强调上下文相关，最好选择协作图。

它也是交互图之一。

识别方式，链，消息这些。

状态图

动态图，展现了一个状态机，描述 单个对象在多个用例中的行为 ，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念，如下：图中方框代表状态，箭头上的代表触发事件，实心圆点为起点和终点。

识别方式，黑色圆点(开始和结束)，有转换、事件触发，监护条件字眼，当然还有组合状态字眼。

活动图

动态图，是 一种特殊的状态图 ，展现了在系统内 从一个活动到另一个活动的流程 。活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个 分岔的分支数代表了可同时运行的线程数 。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动，如下：

特殊状态图，展现了从一个活动到另一个活动的流程。

识别方式，黑色粗横线，不是并发分叉就是并发汇合，黑色圆点是开始和结束。

构件图(组件图)

静态图，为系统静态实现视图，展现了 一组构件之间的组织和依赖 。如下：

构件图/组件图，顾名思义就是这些构件/组件及其相互关系。

识别方式：半圆(供接口)及圆(需接口)，半圆包裹圆(供需接口)，

部署图

静态图，为系统静态部署视图， 部署图物理模块的节点分布 。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。如下：

物理模块的节点分布。识别方式，这个最好识别了立方体或长方体，里面包含各种组件。

UML5种视图

如下图所示：

(1)逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。--展现的是系统功能，系统分析人员和设计人员关心的，表现形式是类与对象。

  

(2)进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。--展现的是并发与同步结构，系统集成人员关心的,

(3)实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。-- 展现的是源代码结构，实现人员(程序员)关心，表现形式是物理代码文件和组件。

(4)部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。-- 展现的是软件构件到物理节点的映射，系统和忘了工程师关心的

  

(5)用例视图。用例视图是最基本的需求分析模型。-- 展现的是需求分析模型，最终用户关心的

3  设计模式

层次结构

架构模式： 软件设计中的高层决策 ，例如 C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策。

设计模式：每一个设计模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。设计模式的核心在于提供了相关问题的解决方案，使得人们可以更加简单方便的复用成功的的设计和体系结构。

设计模式四个基本要素：模式名称、问题(应该在何时使用模式)、解决方案(设计的内容)、效果(模式应用的效果)。

 

惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来

描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用一计数就是C++语言中的一种惯用法。

  

具体设计模式分类

分为三类，创建型模式主要是处理创建对象，结构型模式主要是处理类和对象的组合，行为型模

式主要是描述类或者对象的交互行为，总览图如下：

以下红色字体的记住！！！

创建型：

结构型：

行为型：