软件设计师——面向对象方法（包含设计模式与 UML）

注：本文是针对软件设计师资格考试中重要考点编写的，不可避免地会造成知识点凌乱。

多态

在面向对象技术中，对象在收到消息后要予以响应，不同的对象收到同消息可声生完全不同的结果，这一现象称为多态。 多态有多种不同的形式，其中参数多态和包含多态称为通用多态，过载多态和强制多态称为特定多态。

参数多态应用比较广泛，被称为最纯的多态。这是因为同一对象、函数或过程能以一致的形式用于不同的类型。 包含多态最常见的例子就是子类型化，即一个类型是另一类型的子类型。过载多态是同变量被用来表示不同的功能（就是我们说的重载overload）， 通过上下文以决定一个类所代表的功能。即通过语法对不同语义的对象使用相同的名，编译能够消除这一模糊强制多态（类型转换，int 型转float型）是通过语义操作把一个 变元的类型加以变换，以符合个函数的要求， 如果不做这强制性变换将出现类型错误。 类型的变换可在编译时完成，通常是隐式地进行，当然也可以在动态运行时来做。

类与类之间的关系

类与类之间的关系，常见的有依赖关系、泛化关系(继承关系)、组合关系、聚合关系、实现关系等。
(1)依赖关系。
有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖(Dependency)于元素X。在UML中，使用带箭头的虚线表示依赖关系，如图下所示，

------------------------------------------------------------>：依赖关系的图示

在类中，依赖由各种原因引起，例如，一个类向另 一个类发消息: 一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。如果-一个类的接口改变，它发出的任何消息可能不再合法。

(2)泛化关系。

泛化关系描述一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类是从父类继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示泛化关系，箭头指向父类，如下图所示。
————————————————————>:泛化关系表示
在UML中，对泛化关系有3个要求。

• 子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有；
• 子类中除了有与父类一致的信息外，还包括额外的信息；
• 可以使用父类实例的地方，也可以使用子类实例。

(3)聚合关系。
聚合（Aggregation）是一种特殊形式的关联，是传递与反对称的。聚合表示类之间的关系是整体与部分的关系，例如，一辆轿车包含4个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在UML中，使用一个带空心菱形的实线表示聚合关系，空心菱形指向的是代表“整体”的类。如下图所示：

（4）组合关系
如果聚合关系中表示“部分”的类的存在与否，与表示“整体”的类有这紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示这种关系。在UML中，使用带实心的菱形表示组合关系，如图：

（5）实现关系
实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

用例与用例之间的关系

用例之间存在3种关系，分别是包含关系、扩展关系和泛化关系。

包含关系。当可以从两个或两个以一的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。包含关系的个重要特征， 就是被抽象出来的用例是基础用例必须的部分，不能或缺。本题的描述就是一个包含关系。

扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。扩展关系的一个重要特征，就是抽取的用例相对于基础用例来说不是必须的。

泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式， 子用例继承了父用例所有的结构、行为和关系。例如，某员进行课程注册时，假设既可以通过现场注册，也可以通过网上注册，则“注册课程”用例就是“现场注册”用例和“网上注册”用例的泛化。

面向对象的七大原则

面向对象有七大原则，分别是：单一职责原则

(1）单职责原则(SRP)
就一个类来说，应该仅有一个引起它变化的原因。也就是说，一个类应该只有一个职责。如果有多个职责，那么就相当于把这些职责耦合在一起，一个职责的变化就可能削弱或抑制了这个类完成其他职责的能力，引起类的变化的原因就会有多个。所以在构造一个类时， 将类的不同职责分离至两个或多个类中(或者接口中)，确保引起该类变化的原因只有一一个。

(2)开闭原则(OCP)
软件组成实体应该是可扩展的，但是不可修改。开放-封闭原则认为应该试图设计永远也不需要改变的模块。可以添加新代码来扩展系统的行为，不能对已有的代码进行修改。这个原则很好的实现了而向对象的封装性和可重用性。

(3)替换原则（LSP）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987 年提出的设计原则。它同样可以从Bertrand Meyer的DBC(Design by Contract)的概念推出。以圆和椭圆为例，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。

(4)依赖倒置原则(DIP)
在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，可以看到底层的模块是对高层抽象模块的实现，这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一一个“硬伤”。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。为此，在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类(子类)来实现该业务方法:业务方法内容的修改将不会影响到运行时业务方法的调用。

(5)接口分离原则(ISP)
采用多个与特定客户类有关的接口比采用一个通用的涵董多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP,组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果拥有一一个针对多个客户的类，为每一一个客户创建特定 业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

(6)组合重用原则
就是能用组合实现的地方，尽量用组合来实现，而不要使用继承来扩展功能，因为组合能更好地实现封装，比继承具有更大的灵活性和更稳定的结构。

(7)迪米特原则
指一个对象应该对 于其他对象有最少的了解，即类与类之间的依赖低，或者说没有依赖。这样做的好处就是可以有效地降低类之间的耦合要求。

UML基础

UML中的4种事物

1、结构事物是UML模型中的名次。他们通常是模型的静态部分，描述概念或物理元素。
2、行为事物是UML模型的动态部分。他们是模型中的动词，描述了跨越时间和空间的行为。
3、分组事物是UML模型的组织部分。他们是一些有模型分解成的‘“盒子”。
4、注释事物是UML模型的解释部分。他们是用来描述、说明和标注模型的任何元素。
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图
(1)逻辑视图。逻辑视图也称为设计视图，表示设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

(2)进程视图。进程视图是可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例， 描述了并发与同步结构。

(3)实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。

(4)部署视图。部署视图把构件部署到一组物理结点上，表示软件到硬件的映射和分布结构。

(5)用例视图。用例视图是最基本的需求分析模型。

UML中的14中图

UML2.0中的14种视图可以分为结构性视图(静态)和行为性视图(动态)两种。结构领城主要是对系统中的结构成员及其相互关系进行描述:而行为领域则描述了系统随时间变化的行为。
结构性视图包括类图，对象图、包图，组合结构图、构件图、部署图和制品图，而行为性视图包括用例图，顺序图、通信图、定时图、状态图、活动图、交互概览图。其中顺下图、通信图、定时图和交互概览图又统称为交互图。
在UML2.0包括14种图，分别列举如下:

(1)类图(Class Diagram)

类图描述组类、接口、协作和它们之间的关系。在00系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
###(2)对象图(Object Diagram)
对象图描述组对象及它们之间的关系。 对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

(3)构件图(Component Diagram)

构件图描述一个封装的类和它的接口、 端口，以及由内嵌的构件和连接件构成的内部结构，构件图用于表示系统的静态设计实现视图。对于由小的部作构建大的系统来说，构作图是很重要的。构件图是类图的变体。

(4)组合结构图Composite Structure Diagram)

组合结构图描述结构化类(如构件或类)的内部结构，包括结构化类 与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。

(5)用例图(Use Case Diagram)

用倒图描述组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图，这些图在对系统的行为进行组织和建模时是非常重要的。

(6)顺序图(Sequence Diagram序列图)

顺序图是一种交互图（Interaction Diagram），交互图展现了一种交互， 由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

(7)通信图（Communication Diagram）

通信图也是一种交互图，强调收发消息的
对象或参与者的结构组织。改图反映了对象之间的消息交互，与顺序图相似，但与顺序图不同的是。协代围不但描述了对象之间的交互，还描述了交互的对象之间的链接关系。即通信图时反映了系统的动态和静态特征，在UML1.X版本中，通信图称为协作图(Collaboration Diagram)。

(8)定时图(Timing Diagram,计时图)

定时图也是一种交互图， 强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

(9)状态图( State Diagram)。

状态图描述个状态机， 由状态、转移、事件和活动组成。 状态图给出了 对象的动态视图。它对于接口、类或协作的行为建模尤为重要， 而且它强调事件导致的对象行为，有助于对反应式系统建模。

(10)活动图(Activity Diagram)

活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。

(11)部署图(Deployment Diagram)

部署图描述对运行时的处理结点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个结点包含 一个或多个部暑图。

(12)制品图(Artifact Diagram)

制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。 制品也给出了它们实现的类和构件。

(13)包图(Package Diagram)

包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。

(14)交互概览图(Interaction Overview Diagram)

交互概览图是活动图和顺序图的混合物。

设计模式

Adapter（适配器）

该设计模式的意图是将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

适用性:想使用一个已经存在的类，而它的接口不符合需求。
想创建一个可以复用的类， 该类可以与其他不相 关的类或不可预见的类(即那些接口可能不一定兼容的类) 协同工作。(仅适用于对象Adapter)想使用些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。

Prototype（原型）

(2) Prototype (原型)设计模式的意图是用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。

适用性:当要实例化的类是在运行时刻指定时。例如，通过动态装载:或为了避免创建一个与产品类层次平行的工厂类层次时:或当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一-些。

Iterator（迭代器）

(3) Iterator (迭代器)设计模式的意图是提供一种 方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

适用性:访问一个聚合对象的内容而无须暴露它的内部表示。迭代器模式支持对聚合对象的多种遍历。也为遍历不同的聚合结构提供一个统的接口(即支持多态迭代)。

Observer（观察者）

(4) Observer (观察者)设计模式，定义对象间的= 种对多的依赖关系,当一 一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

适用性:当一个抽象模型有两个方面，其中一不方面依赖丁另方面。 将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。以下两种情况比较适合观察者模式:一个是当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变:另一个是当一个对象必须通知其他对象，而它又不能假定其他对象是谁。换言之，你不希望这些对象是紧密耦合的。

Brige（桥接模式）

桥楼模式的意图是将抽象部分与它的实现部分分离。桥接模式的适用性如下:
(1)避免抽象方法和实现方法绑定在一起。
(2)类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。
(3)对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新
编译。
(4)想在多个对象间共享实现(可能使用引用计数)，但同时要求客户并不知道这一点。
桥接模式是把继承关系变成合成/聚合关系。手机可以按照品牌来分类，则有手机品牌M,手机品牌N之分，现在的每个手机都有很多软件，如通信录，手机游戏等。运用桥接模式，可把手机系统划分为品牌和软件，使它们可以独立的变化。
q桥接模式可以从接口中分离实现功能，使得设计更具有扩展性，这样，客户调用方法时根本不需要知道实现的细节.桥接模式的缺陷是抽象类和实现类的双向连接使得运行速度减慢。

Single（单例模式）

单侧模式确保其个一类只有一个实例， 而且自行实例化并向整个系统提供这个实例。这个类称为单例类，它提供全局访问的方法。单例模式的要点有三个:一是某个类只能有一个实例；二是它必须自选创建这个实例；三是它必须自行向整个系统提供这个实例。

Composite（组合模式）

组合(Composite)设计模式组合多个对象形成树形结构以表示整体部分的结构层次。合成模式对单个对象和合成对象的使用具有一致性。

Facade（外观模式）

外观(Facade) 模式，有称为门面模式，其提供了一个统一一的接口去访问多个子系统的多个不同的接口。外观模式定义了一个高层次的接口，使得子系统更容易被使用。

Decorator（装饰器模式）

装饰器模式是动态地给一个对象添加一些额外职责。在需要某个对象而不是整个类添加一些功能时使用。这种模式对增加功能比生成子类更加灵活。

Proxy（代理模式）

代理模式通过提供与对象相同的接口来控制对这个对象的访问，以使得在确实需要这个对象时才对他进行创建和初始化。

作用

设计模式主要有以下几个方面的作用:

(1)重用设计，重用设计比重用代码更有意义，它会自动带来代码重用。

(2)为设计提供共同的词汇，每个模式名就是一个设计词汇，其概念是的程序员间的交流更加方便。

(3)在开发文档中采用模式词汇可以让其他人更容易理解你的想法和做法，编写开发文档也更加容易。

(4)应用设计模式可以让重构系统变得容易，可确保开发正确的代码，并降低在设计或实现中出现错误的可能。

(5)支持变化，可以为重写其他应用程序提供很好的系统架构。(6)正确使用设计模式，可以节省大量时间。

另外，设计模式还有适应需求变化的优点，如职责链模式，当系统业务流程有变化时，只需要很少的调整即可达到目的。

应付软考No Problem

每种设计模式都有特定的意图，描述一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，使该方案能够重用而不必做重复劳动。

责任链(Chain of Resposiblity)模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这些对象连成条链， 并沿着这条链传递该请求，直到有一个对象处理它为止。
命令(Command)模式将- -一个请求封装为一个对象，从而使得使用者可以采用不同的请求对客户进行参数化:对请求排队或记录请求日志，以及支持可撤销的操作。

抽象工厂(Abstract Factory)模式提供一- 个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

观察者(Observer)模式定义对象间的一种一对多 的依赖关系，当一-个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

原型(Prototype) 模式用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

工厂方法(Factory Method)定义一个用于创建对象的接口， 让子类决定将哪一个类实例化，使一个类的实例化延迟到其子类。

单例(Singleton)模式是指系统运行过程中，一个类只有 一个对象实例。

生成器(Builder) 模式将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

适配器(Adapter)模式将一个类的接口转换成客户希望的另外一个接口， 使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

桥接(Brige)模式将抽象部分与其实现部分分离，使它们都可以独立地变化。组合(Composit)模式将对象组合成树形结构以表示“部分整体” 的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

装饰器Ceonmto)) 模式描述了以透明围栏来支持修饰的类和对象的关系，动态地给个对象添加一些额外的职责， 从增加功能的角度来看，装饰器模式相比生成子类更加灵活。

策略(Strategy)设计模式定义一系列算法，把它们一个个封装起来，并且使它们可以相互替换。这一模式使得算法可独立与它的客户而变化。

抽象工厂(Abstract Factory)模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。

状态(State)模式是使得一个对象在其内部状态改变时通知调用另一个类中的方法改变其行为，使这个对象看起来如同修改了它的类。

组合(Composite)模式将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。组件Component为组合的对象声明接口，通常定义父组件引用。
****