面向对象设计-课件

1/8210.1架构设计第10章面向对象设计10.2详细设计10.3设计模式1/8210.1架构设计第10章面向对象设计10.22/82教学目的与要求⒈掌握架构设计的概念和原则;⒉掌握常用的架构摸式;⒊掌握详细设计原则和设计内容；4.了解各种设计模式；

2/82教学目的与要求⒈掌握架构设计的概念和原则;3/82教学重点

⒈架构设计的概念和原则;

⒉常用的架构摸式;

⒊详细设计原则和设计内容;

⒋设计模式。教学难点

⒈架构设计的概念;

⒉常用的架构摸式;

3.详细设计原则和设计内容。3/82教学重点

⒈架构设计的概念和原则;

⒉常用的架构摸4/8210.1架构设计一、软件架构与框架（1）什么是软件架构软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。一个软件里有处理计算的、处理界面的、处理数据的、处理业务规则的、处理安全的等许多可逻辑划分出来的部分。软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将他们有机的结合在一起，形成职责清晰、结构清楚的软件结构。软件架构是一个逻辑性的框架描述，它可能并无真正的可执行部分。大部分的软件架构都是由一个设计思想，加上若干设计模式，在规定一系列的接口规范、传输协议、实现标准等文档构成的。4/8210.1架构设计一、软件架构与框架（1）什么是5/8210.1架构设计

软件框架是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。因此，如果说架构是一个逻辑的构成，而框架则是一个可用的半成品，是可执行的。二、软件架构的基本组成

一个软件架构应当包括软件层次、每一层次的职责、层次之间的接口、传输协议和标准以及每一层次上所采用的软件框架5/8210.1架构设计软件框架是软件架构的6/82软件架构的内容6/82软件架构的内容7/82在Rose中，我们可以用包图来描述软件架构。如下图所示，描述了一个由五个层次构成的软件架构。7/82在Rose中，我们可以用包图来描述软件架构。如下图所8/8210.1架构设计三、架构设计原则自顶向下原则职能集中原则互不交叉原则8/8210.1架构设计三、架构设计原则自顶向下原则9/82

自顶向下分包原则9/82自顶向下分包原则10/82职能集中原则10/82职能集中原则11/82增加新类并单独分包交叉依赖的类单独分包11/82增加新类并单独分包交叉依赖的类单独分包12/8210.1架构设计四、常用的架构模式分层架构模式

分层（Layer）模式是最常见的一种架构模式。甚至说分层模式是很多架构模式的基础。分层描述的是这样一种架构设计过程：从最低级别的抽象开始，称为第1层。这是系统的基础。通过将第J层放置在第J-1层的上面逐步向上完成抽象阶梯，直到到达功能的最高级别，称为第N层。如图下所示。12/8210.1架构设计四、常用的架构模式分层架构模13/82分层架构模式13/82分层架构模式14/82分层构架具有以下优点：层次的复用性。为每个层次建立好抽象接口，可以使其在其他环境复用。支持基于抽象程度递增的系统设计，使设计者可以对复杂系统进行分解，从而使系统更容易模块化。支持功能增强。因为每一层至多和相邻的上下层进行交互，因此功能的改变最多影响相邻的两层。可替换性。独立的层次设计容易被功能相似的模块替换。分层构架也有一些缺点，主要表现在：效率低。分层结构通常要比单层结构效率低，原因是有时高层过分依赖底层的服务，必须经过许多中间层进行数据传递。增加了一些不必要的工作。改变行为的连锁反应。设计者要建立不同合适粒度的抽象层次有一定困难。常见的分层架构模式有：客户端-服务器模型（Client-Server，C/S）。三层模型：用户表示层、业务逻辑层、数据层。14/82分层构架具有以下优点：15/8210.1架构设计四、常用的架构模式2.黑板模式

黑板模式的思想是，有一系列独立的模块，或者说是方案，这些方案能解决部分问题的一部分，这些方案进行协作，使得问题问题能够最终解决。这就像一群人在一块

黑板前，共同解决一个问题，根据当前问题解决的程度和状态，不同的人上前到黑板上解决他所能解决的部分，这样经过多人的协作，最终能够将问题解决。这就是

黑板模式这个名字的来历。黑板模式的实现分为三个主要的组件：黑板(Blackboard)，知识源(KnowledgeSource)和控制(Control)。。如图下所示。15/8210.1架构设计四、常用的架构模式2.黑板模16/82黑板模式16/82黑板模式17/8210.1架构设计四、常用的架构模式3.管道/过滤器模式

管道/过滤器模式构架中的每个构件都有一组输入和输出，构件读入数据流，经过处理产生输出数据。这个过程通过对输入流的变换及增量计算来完成，因此在输入流被完全使用掉之前，变产生了输出，这样的构件就是过滤器，而构件间的连接件就像是数据流传输的管道，它将数据从一个过滤器传到另一个过滤器。其中，过滤器必须是独立的实体，它不能与其他的过滤器共享数据。多个过滤器相连，可以形成过滤器链。而每个过滤器功能单一，可以单独修改，链中过滤器的排列顺序可以根据需求进行配置。17/8210.1架构设计四、常用的架构模式3.管道/18/82特征：每个过滤器构件是一个独立的部件，除了输入流和输出流外，过滤器之间互不影响，因此，过滤器之间不共享任何状态信息。每个过滤器对其上游或下游连接的过滤器是透明的，它的实现和使用不对链中的任何过滤器加以限制。如下图所示。管道/过滤器模式18/82特征：管道/过滤器模式19/82这种构架具有以下优点：可以创建具有良好隐蔽性和高内聚、低耦合的构件。设计者可以将整个系统的输入/输出行为看成是多个过滤器行为的简单合成。支持软件重用。通过添加新的过滤器或换掉旧的过滤器可以方便地维护系统，增强现有的系统功能。可以对一些如吞吐量、死锁等问题进行分析。支持并发过程。每个过滤器作为一个单独的任务完成，因此可与其他任务并行执行，有较高的并行处理效率。19/82这种构架具有以下优点：20/8210.1架构设计四、常用的架构模式4.中介模式

中介模式是构建带有隔离构件的分布式系统，系统通过远程服务调用进行交互。中介构件负责协调通信，包括转发请求、传送结果和异常等。这样的构架模式并不是一个整体的应用程序，而是若干个独立的和互操作的构件集合。通过将功能分割成独立的构件，系统具有可分割性和可扩展性，并具有较大的灵活性、可维护性和可变性。在中介构架中，系统可以添加、移动、交换、激活和定位构件服务，可以仅通过对象接口使用服务器中的应用程序对象，而不需要要知道对象的细节或其物理位置。20/8210.1架构设计四、常用的架构模式4.中介模21/8210.1架构设计四、常用的架构模式5.代理模式

代理模式由是客户机、服务器、代理程序、桥接、客户端代理和服务器端代理等构件组成的构架模式。客户机通过代理程序发送请求访问服务器功能。服务器为应用领域提供公共服务，或者向单一应用提供特定的功能服务。代理程序位于客户机和服务器之间，协调客户机和服务器之间的活动。21/8210.1架构设计四、常用的架构模式5.代理模22/82客户机端代理是客户机和代理程序之间的一个层。桥接是用来隐藏两个代理程序互相操作的细节的可选构件，它建立一个所有系统细节封装起来的层，便于系统在异构环境中运行。

通过使用代理模式，应用程序能够简单地通过向合适的对象发出消息调用访问分布式服务，而不是把重点放在低级进程间通信。另外，代理模式结构灵活，允许对对象动态改变、添加、删除和重定位。22/82客户机端代理是客户机和代理程序之间的一个层。桥接23/8210.1架构设计四、常用的架构模式6.MVC模式

MVC是模型-视图-控制器(Model-View-Control)的简称，是一种流行的系统开发框架。MVC把交互系统的组成分解成模型、视图、控制三种部件。如下图所示。23/8210.1架构设计四、常用的架构模式6.MVC24/82MVC模式24/82MVC模式25/82模型部件是软件所处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象，封装了问题的核心数据、逻辑和功能的计算关系，他独立于具体的界面表达和I/O操作。视图部件把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。控制部件是处理用户与软件交互操作的，其职责是控制提供模型中任何变化的传播，确保用户界面于模型间的对应联系；它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制。模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。25/82模型部件是软件所处理问题逻辑在独立于外在显示内容和26/82MVC的优点表现在以下几个方面：可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。26/82MVC的优点表现在以下几个方面：27/8210.1架构设计四、常用的架构模式7.PAC模式

PAC是表示-抽象-控制(Presentation-Abstraction-Control)的简称，它也是从数据模型及界面可视化的处理中提出的交互式系统构架。PAC将用户界面从数据管理中分离出来，从而降低了部件间的耦合度。如下图所示。27/8210.1架构设计四、常用的架构模式7.PAC28/8210.1架构设计四、常用的架构模式8.反射模式

反射模式是为动态地改变系统结构和行为提供相应机制的架构模式。它使系统维护了自身的信息，并使用这种信息来保持系统的可变性和可扩展性。一个反射系统在实现方面处于开放状态，以支持特定的结构和行为。

反射构架由两部分组成：元层次(MetaLevel)和基本层次(BaseLevel)。反射架构模式有以下优点：反射系统不直接修改源代码。系统更新简单易行。支持多种类型的变更。28/8210.1架构设计四、常用的架构模式8.反射模29/8210.1架构设计四、常用的架构模式8.反射模式

反射模式是为动态地改变系统结构和行为提供相应机制的架构模式。它使系统维护了自身的信息，并使用这种信息来保持系统的可变性和可扩展性。一个反射系统在实现方面处于开放状态，以支持特定的结构和行为。

反射构架由两部分组成：元层次(MetaLevel)和基本层次(BaseLevel)。29/8210.1架构设计四、常用的架构模式8.反射模30/8210.1架构设计四、常用的架构模式9.微核模式

微核是为应对需求变化所引起的系统更改而采取的一种架构设计。这种架构强调应用系统的自修改和自扩展能力，使系统的变化与更新不影响其核心功能及关键设计，从而降低为适应不断变化的需求必须进行的系统维护成本，使系统易于移植、扩展和集成不断出现的新构件，具有高度适应性并能满足客户特殊的定制需求。30/8210.1架构设计四、常用的架构模式9.微核模31/82微核模式由以下5个部分组成：内部服务器外部服务器适配器客户机微核31/82微核模式由以下5个部分组成：32/8210.2详细设计一、详细设计原则单一职责原则“开-闭”原则里氏代换原则合成复用原则依赖倒置原则接口隔离原则迪米特原则32/8210.2详细设计一、详细设计原则单一职责原则33/8210.2详细设计二、类设计类设计就是根据具体的实现语言将分析类转换成设计类，即按具体的实现语言，如Java、C#等，对分析类中的边界类、实体类和控制类细化已有方法、补充类属性，完成基本设计模型。类设计是将分析模型映射到设计模型最基础也是最重要的一项工作。以学生选课这个系统用例为例，并且假设我们使用java语言来开发。在建立分析模型的过程中，我们得到了如下图所示的实现了学生选课系统用例的分析模型类图。33/8210.2详细设计二、类设计类设计就是根据具体34/82学生选课用例分析模型34/82学生选课用例分析模型35/82分析类直接映射到设计类

上图所示的分析模型中，学生信息类已经非常接近设计类了，我们只需要将其属性和方法完善直接映射到设计类即可。如右图所示，学生信息类包含的属性有姓名、出生年月、性别、籍贯、入学时间、所属系别、班级、学号，同时为了与系统实现一致我们为其增加Id属性，包含的方法有设置和获取属性的方法，在这里我们分别为每个属性定义设置和获取的方法。学生信息设计类35/82分析类直接映射到设计类上图所示的分析模型中36/82分析类映射到多个设计类选课控制类映射到设计类系统选课栏目边界类映射到设计类36/82分析类映射到多个设计类选课控制类映射到设计类系统37/82分析模型映射设计模型

将分析类都映射到设计类后，将得到的设计类集中在一张图中，绘制出这些设计类之间的关系，就得到了设计模型。下面两图分别展示了学生选课系统用例在Web层的设计模型和，学生选课系统用例在Business层的设计模型。37/82分析模型映射设计模型将分析38/82学生选课web层设计模型38/82学生选课web层设计模型39/82学生选课Business层设计模型39/82学生选课Business层设计模型40/82对分析类的补充

将分析模型映射到设计模型后，得到了设计类及设计类之间的关系，至此得到了完整的静态设计模型。在比较复杂的系统设计中，静态图往往还不足以指导开发，这时有必要绘制设计类的交互图来说明这些类如何交互完成设计功能。下图展示了Business层学生选课设计类交互图。

40/82对分析类的补充将分析模型映射到设计模41/82Business层的学生选课设计类交互图41/82Business层的学生选课设计类交互图42/8210.2详细设计三、接口设计面向对象的一大优点是接口与实现的分离，它使得我们在考虑程序逻辑时可以完全不用考虑程序将怎样编写，而只考虑对象交互的接口。面向对象设计中，软件系统四通八达的神经网络正是通过接口设计来构建的。接口使对象之间相互传递消息从而构成整个系统。接口设计不良会导致消息处理出错从而造成系统功能失效接口决定了整个系统是否能正常运行。42/8210.2详细设计三、接口设计面向对象的一大优43/82为单个对象设计接口

典型的单个对象通常是封装某种算法，例如业务规则计算对象和业务逻辑处理对象。这些对象由于业务规则和业务逻辑的特殊使得它们很可能具有与众不同的方法。虽然这些对象没有抽象价值，但我们可以简单的为这些对象设计单独的接口，将它们的方法提取出来形成“接口实现”的形式为我们保留了替换实现类的可能。如10.2.3类设计一节中从分析类映射而来的处理选课业务逻辑的Business层的OfferuleControl这个类，他的方法是独特的，没有抽象价值，我们可以简单的将它的方法提取出来形成接口，接口设计结果如下图所示。43/82为单个对象设计接口典型的单44/82单个对象接口实现设计实例44/82单个对象接口实现设计实例45/82为具有相似性的对象设计接口在一个系统里会有许多具有相同或相似的行为模式。通常，这些对象承担着相同或相似的职责，即它们处理事情的办法都差不多，但处理的内容和具体过程可能不同。典型的具有相同或相似行为模式的对象是实体对象。实体对象主要作用是封装业务数据和对业务数据的操作方法。虽然实体对象封装的业务数据千差万别，但操作数据的方法无非增删改查。这是典型的行为相似内容不同的对象的例子。45/82为具有相似性的对象设计接口在一个系统里会有许多具有46/82具有相似行为对象接口设计实例46/82具有相似行为对象接口设计实例47/82为软件各层次设计接口

一个多层次的软件架构中，各层次之间的交互是错综复杂的。软件按层次分开的目的是为了使得各软件层职责清晰，各负其责。但是如果层次之间的交互过程没有很好的接口设计，软件分层带来的好处可能会完全丧失。如选课系统例子中，Web层与Business层之间的交互是由各种Action类和BussinessControl类来完成的。Action类的数量非常庞大，BussinessControl类的数量也很可观，在没有良好接口设计的情况下，WEB层与Business层之间的交互情况如下图所示错综复杂。47/82为软件各层次设计接口一个多层次的软件架48/82无良好接口设计的层次交互48/82无良好接口设计的层次交互49/82采用门面模式后的层次交互

采用门面模式来处理Web层和Business层之间的交互可以有效地减少交互的复杂度，使得层次之间保持清晰的关联。如下图所示，交互的复杂层度得到了有效的控制。49/82采用门面模式后的层次交互采用门面50/8210.3设计模式一、设计模式与分类设计模式提供一种解决问题的纲要设计，它描述普遍存在的在相互联系的构件中重复出现的结构，从而建立在一定的问题背景下通用的设计方案。设计模式通常被分成创建型、结构型、行为型三类。二、创建型设计模式1.工厂模式

工厂模式通过一个通用的工厂方法来生成对象，并专门负责将大量有共同接口的类实例化。工厂模式有简单工厂模式、工厂方法模式、抽象工厂模式三种。50/8210.3设计模式一、设计模式与分类设计模式提51/82简单工厂模式工厂方法模式51/82简单工厂模式工厂方法模式52/82抽象工厂模式52/82抽象工厂模式53/8210.3设计模式二、创建型设计模式2.单例模式单例(Singleton)模式又叫单件模式，它保证一个类仅有一个实例，并且提供一个对它的全局访问点。即单例类必须自己创建自己的唯一实例，保证没有其他实例可以被创建，并提供一个访问该实例的方法。单例结构如下图所示。53/8210.3设计模式二、创建型设计模式2.单例模54/82

单例模式的参与者只有一个，即Singleton。Singleton拥有一个私有的构造函数，确保无法通过new直接将其实例化。此外，该类还高含有一个静态私有成员变量instance和静态公有方法getInstance()。getInstance()负责检验并实例化Singleton，然后存储在静态成员变量instance中，确保只有一个实例被创建。单例模式54/82单例模式的参与者只有一个，即Sing55/8210.3设计模式三、结构型设计模式1.享元模式享元模式以共享的方式高效地支持大量的细粒度对象。享元对象能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态是存储在享元对象内部并且不会随环境改变而改变，因此内蕴状态可以共享。外蕴状态是随环境改变而改变的、不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态与内蕴状态是相互独立的。55/8210.3设计模式三、结构型设计模式1.享元模56/82享元模式所涉及的角色有：抽象享元(Flyweight)角色。具体享元(ConcreteFlyweight)角色。享元工厂(FlyweightFactory)角色。客户端(Client)角色。享元模式56/82享元模式所涉及的角色有：享元模式57/822.门面模式门面模式为一组复杂接口对象提供简单且特定的接口，以供外界使用。门面将子系统与客户及其它子系统分离，可以提供高子系统的独立性和可移植性。门面模式要求子系统的外部必须通过统一的接口与其内部进行通信，该模式提供一个高级的接口，使得子系统更易于使用。门面模式由三个角色组成：门面角色子系统角色客户角色。57/822.门面模式58/823．桥接模式桥接(Bridge)模式是将抽象(Abstraction)与实现(Implementation)脱耦，使得二者可以独立地变化。耦合是两个实体间的某种强关联，脱离就是去掉它们间的强关联，即将两个对象间的继承关系改为聚合关系。采用继承的情况下，具体实现依赖于抽象定义，抽象定义被看作是相对稳定的。而对于像多个维度变化激烈的对象来说，抽象定义也是不稳定的。这时候，如果想尽可能付出小的代价，获得最大的扩展，就可以采用桥接模式。桥接模式涉及的角色如下:58/823．桥接模式59/82抽象(Abstraction)对象：抽象对象给出的定义，并保存一个对象实现者(Implementor)对象的引用精化(RefinedAbstraction)抽象：扩展抽象对象，改变和修正父类对抽象的定义。实现者(Implementor)对象：给出实现者对象的接口，但不给出具体的实现方法。具体实现(ConcreteImplementor):给出实现者对象接口的实现方法。59/82抽象(Abstraction)对象：抽象对象给出的60/824．代理模式代理模式就是为其他对象提供一种代理以控制对这个对象的访问。就是，在一些情况下客户不想或者不能直接引用一个对象，而代理对象可以在客户和目标对象之间起到中介作用，去掉客户不能看到的内容和服务或者增添客户需要的额外服务。常见的代理：远程代理：为一个对象在不同的地址空间提供局部代理。虚拟代理：根据需要创建开销很大的对象。保护代理：控制对原始对象的访问，用于对象应该有不同的访问权限时。智能引用：取代了简单的指针，在访问对象时执行了一些附加操作。60/824．代理模式61/82如图所示，客户对象(Client)向一个作为接口的Subject发出请求，Subject接口的实施代理对象Proxy根据请求的种类，在适当的时候向RealSubject转发请求。代理模式的参与者如下：客户对象(Client)：向一个作为接口的Subject发出请求。代理对象(Proxy)：保存一个引用使其可以访问实体。抽象类(Subject)：定义实体目标对象RealSubject和代理对象Proxy的共用接口，这样就允许在任何使用RealSubject的地方都可以使用Proxy。实体目标对象(RealSubject)：定义代理对象Proxy所代表的实体。61/82如图所示，客户对象(Client)向一个作为接口的62/825．适配器模式适配器(Adapter)模式又叫包装(Wrapper)模式，指把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。适配器模式有类适配器和对象适配器两种。类适配器使用多重继承使一个接口与另一个接口进行匹配，类适配器模式如下图所示。由图可看出，类Adaptee类没有request方法，而客户期待这个方法。为了是客户能够使用Adaptee类，提供一个中间环节，即Adapter类，Adapter类实现了Target接口，并继承自Adaptee类，Adapter类的Request方法重新封装了Adaptee的specificRequest方法，实现了适配的目的。因为Adapter和Adaptee是继承关系，所以决定了这个适配器模式是类的。类适配器模式所涉及的参与者包括：目标(Target)：客户端所期待的接口。源(Adaptee)：需要适配的类。适配器(Adapter)：把源接口转换成目标接口，它必须是类。62/825．适配器模式63/82类适配器模式63/82类适配器模式64/82对象适配器依赖于对象组合，如下图所示。从图中可以看出：客户端需要调用request方法，而Adaptee没有该方法，为了使客户端能够使用Adaptee类，需要提供一个包装(Wrapper)类Adapter。这个类包装了一个Adaptee类的实例，从而将客户端与Adaptee衔接起来。由于Adapter与Adaptee是委派关系，从而决定了这个适配器模式是对象的。该适配器模式所涉及的参与者包括：目标(Target)：客户所期待的接口。源(Adaptee)：是需要适配的类。适配器(Adapter)：通过内部包装一个Adapter对象，把源接口转换成目标接口。64/82对象适配器依赖于对象组合，如下图所示。65/82对象适配器模式65/82对象适配器模式66/8210.3设计模式四、行为型设计模式1.调停者模式

通常，面向对象应用程序是由一组为了提供某种服务而彼此交互的对象组成，这组对象叫同事对象。当彼此引用的对象数量比较少时，此时对象之间就为直接交互。当对象的数量增加时，这种直接交互会导致对象之间复杂的、混乱的引用。这就会影响应用程序的可维护性。同时，因为对象之间的高耦合，当一个对象直接引用其他的对象时，缩小了这些对象的复用范围。调停者模式推荐抽象所有同事对象交互的细节到一个独立的类，这个类就是调停者，它负责这组对象之间的交互。这组对象中的每一个对象仍然负责提供它所具有的服务，但为了提供服务，对象之间不能直接彼此交互。两个不同对象之间的交互通过调停者进行路由。所有的对象把消息发送给调停者。调停者依据应用程序的需求把消息再发送给相应的对象。66/8210.3设计模式四、行为型设计模式1.调停者67/82如图所示:调停者模式的参与者如下：调停者：调停者定义一个接口用于与各同事对象进行通信具体调停者：具体调停者通协调各同事对象实现协作行为，了解并维护它的各个同事。同事类：同事类定义出调停者到同事对象的接口。具体同事类：每一个具体同事类都知道它的调停者对象，在需要与其他同事通信时，仅仅与它的调停者进行通信。67/82如图所示:调停者模式的参与者如下：68/822．策略模式策略模式是针对一组算法，将每一个算法(策略)封装到具有共同接口的独立类中，使得他们可以相互替换。策略模式是对算法的包装，是将使用算法的责任和算法本身分割开，委派给不同的对象进行管理。策略模式可以把行为和环境分开。其中，环境类负责维持和查询行为类，而各种算法在具体策略类中提供。这样算法的增减和修改都不会影响环境和客户端。当出现需求变化时，只需要实现新的策略类，并在客户端登记即可。68/822．策略模式69/82如下图所示:策略模式涉及3个参与者：语境(Context)：持有一个策略类(Strategy)的引用。可以定义一个接口让Strategy访问它的数据。抽象策略(Strategy)：通常由一个接口或抽象类实现，它给出所有的具体策略类所需要的接口。具体策略(ConcreteStrategy)：包装了相关的算法或行为，以Strategy接口实现某个具体算法。 69/82如下图所示:策略模式涉及3个参与者：70/823．观察者模式观察者模式定义了一种一对多的依赖关系，此模式的关键对象是目标和观察者，它让多个观察者对象同时监听某一个目标对象。该目标对象发生变化时，会通知所有观察者，作为响应，观察者将对目标进行查询并自动更新，以使其状态与目标同步。目标是通知的发布者，它只需发出通知，而不需要知道观察者是谁.观察者可以有任意多个。如下图可知，ConcreteSubject一旦发生可能导致其观察者与自身状态不一致的变化时，将通知它的各个观察者。在得到一个具体改变通知后，ConcreteObserver可向目标对象查询信息。ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。70/823．观察者模式71/82观察者模式71/82观察者模式72/82观察者对象的参与者如下：目标对象(Subject)：知道自己的观察者对象Observer，并提供注册和删除Observer的接口，一个Subject可以有任意多个Observer。抽象观察者类(Observer)：为所有的具体观察者定义一个接口，在得到目标的通知时更新自己。此接口叫做更新接口。抽象观察者角色一般用一个抽象类或者一个接口来实现。在这个示意性的实现中，更新接口只包含一个方法(update()方法)，该方法叫做更新方法。具体目标对象(ConcreteSubject)：将有关状态存入各个ConcreteObserver，当ConcreteSubject自身状态发生变化时，会向它的各个Observer发出通知。具体观察者对象(ConcreteObserver)：维护一个指向ConcreteObserver的引用，存储有关状态，并更新观察者对象Observer接口，以使存储状态、自身状态与目标对象Subject状态保持一致。72/82观察者对象的参与者如下：73/824．命令模式命令模式是对命令的封装，该模式把发出命令和执行命令的责任分开，委派给不同的对象。每一个命令都是一个操作：请求方要求执行操作；接收方收到请求，并执行操作。命令模式允许请求方和接收方相互独立，这样请求方不必知道接收方的接口，也不必知道请求怎么被接受，操作是否被执行以及何时怎么被执行的。命令模式的关键是一个抽象的命令类Command，它定义了一个执行操作的接口，其最简单的形式是一个抽象的Execute()操作。命令模式的结构类图如下图所示。73/824．命令模式74/82命令模式Client类创建一个具体命令对象ConreteCommand，并指定它的接收对象Receiver，其中某一个Invoker对象存储ConcreteCommand，并通过调用ConcreteCommand的执行操作Execute()提交一个请求。如果撤销命令，ConcreteCommand就执行操作Execute()之前存储当前状态以便取消该命令。ConcreteCommand调用它的接收对象Receiver的一些操作以执行该请求。74/82命令模式Client类创建一个具体命令对象Con75/82命令模式运行的参与者如下：客户(Client)：创建一个具体命令(ConcreteCommand)对象并确定其接收者。命令(Command)：声明了一个给所有具体命令类的抽象接口，这是一个抽象角色。具体命令(ConcreteCommand)：定义一个接收者和行为之间的弱耦合；实现Execute()方法，负责调用接受者的相应操作。Execute()方法通常叫做执行方法。请求者(Invoker)：负责调用命令对象执行请求，相关的方法叫做行动方法。接收者(Receiver)：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。75/82命令模式运行的参与者如下：76/825．解释器模式解释器(Interpreter)定义语言的文法，并且建立一个解释器来解释该语言中的句子。当某种问题发生频率很高时，就需要构建一个解释器，将该问题的各个实例表述为一个简单语言的句子。解释器模式的类图结构如下图所示。76/825．解释器模式77/82解释器模式的参与对象如下：抽象类(AbstractionExpression)：声明一个抽象的解释操作，被抽象语法树中所有的结点共享。终结符表达式结点类(TerminalExpression)：实现与文法中的终结符相关联的解释操作。非终结符表达式结点类(NonterminalExpression)：解释一般要递归地调用表示每一条规则的那些对象的解释操作。语境类(Context)：包含解释器之外的一些全局信息。客户类(Client)：构建表示该文法定义的语言中一个特定句子的抽象语法树。77/82解释器模式的参与对象如下：78/826．访问者模式访问之(Visitor)模式表示一个作用于某对象结构中的各元素的操作，使得可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作可以相对自由地演化。访问者模式结构如下图所示。78/826．访问者模式79/82访问者模式79/82访问者模式80/82访问者模式的参与者如下：抽象访问者(Visitor)：声明了一个或者多个访问操作，形成所有的具体元素角色必须实现的接口。具体访问者(ConcreteVisitor)：实现抽象访问者角色所声明的接口，即抽象访问者所声明的各个访问操作。抽象节点(Node)：实现了抽象元素所规定的接受操作。结构对象(ObjectStructure)：有如下的一些责任，可以遍历结构中的所有元素。如果需要，提供一个高层次的接口让访问者对象可以访问每一个元素；如果需要，可以设计成一个复合对象或者一个聚焦，例如列或集合。80/82访问者模式的参与者如下：81/827．状态模式状态模式允许一个对象在其内部状态变化时改变它的行为，例如打电话时有不同的状态：拨号、通话和挂机等。被呼叫方收到其它对象的请求时，会根据自身的状态做出相应的响应。此时，可以使用一个抽象类来表示各种状态。状态模式的结构图如下图所示。81/827．状态模式82/82状态模式的参与者如下：语境对象(Context)：定义客户感兴趣的接口，并维护ConcreteState子类的实例，这个实例定义当前状态。抽象类(State)：定义一个接口，以封装与Context的特定状态相关的行为。具体状态类(ConcreteState)子类：实现了一个与Context的状态相关的行为。82/82状态模式的参与者如下：83/8210.1架构设计第10章面向对象设计10.2详细设计10.3设计模式1/8210.1架构设计第10章面向对象设计10.284/82教学目的与要求⒈掌握架构设计的概念和原则;⒉掌握常用的架构摸式;⒊掌握详细设计原则和设计内容；4.了解各种设计模式；

2/82教学目的与要求⒈掌握架构设计的概念和原则;85/82教学重点

⒈架构设计的概念和原则;

⒉常用的架构摸式;

⒊详细设计原则和设计内容;

⒋设计模式。教学难点

⒈架构设计的概念;

⒉常用的架构摸式;

3.详细设计原则和设计内容。3/82教学重点

⒈架构设计的概念和原则;

⒉常用的架构摸86/8210.1架构设计一、软件架构与框架（1）什么是软件架构软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。一个软件里有处理计算的、处理界面的、处理数据的、处理业务规则的、处理安全的等许多可逻辑划分出来的部分。软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将他们有机的结合在一起，形成职责清晰、结构清楚的软件结构。软件架构是一个逻辑性的框架描述，它可能并无真正的可执行部分。大部分的软件架构都是由一个设计思想，加上若干设计模式，在规定一系列的接口规范、传输协议、实现标准等文档构成的。4/8210.1架构设计一、软件架构与框架（1）什么是87/8210.1架构设计

软件框架是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。因此，如果说架构是一个逻辑的构成，而框架则是一个可用的半成品，是可执行的。二、软件架构的基本组成

一个软件架构应当包括软件层次、每一层次的职责、层次之间的接口、传输协议和标准以及每一层次上所采用的软件框架5/8210.1架构设计软件框架是软件架构的88/82软件架构的内容6/82软件架构的内容89/82在Rose中，我们可以用包图来描述软件架构。如下图所示，描述了一个由五个层次构成的软件架构。7/82在Rose中，我们可以用包图来描述软件架构。如下图所90/8210.1架构设计三、架构设计原则自顶向下原则职能集中原则互不交叉原则8/8210.1架构设计三、架构设计原则自顶向下原则91/82

自顶向下分包原则9/82自顶向下分包原则92/82职能集中原则10/82职能集中原则93/82增加新类并单独分包交叉依赖的类单独分包11/82增加新类并单独分包交叉依赖的类单独分包94/8210.1架构设计四、常用的架构模式分层架构模式

分层（Layer）模式是最常见的一种架构模式。甚至说分层模式是很多架构模式的基础。分层描述的是这样一种架构设计过程：从最低级别的抽象开始，称为第1层。这是系统的基础。通过将第J层放置在第J-1层的上面逐步向上完成抽象阶梯，直到到达功能的最高级别，称为第N层。如图下所示。12/8210.1架构设计四、常用的架构模式分层架构模95/82分层架构模式13/82分层架构模式96/82分层构架具有以下优点：层次的复用性。为每个层次建立好抽象接口，可以使其在其他环境复用。支持基于抽象程度递增的系统设计，使设计者可以对复杂系统进行分解，从而使系统更容易模块化。支持功能增强。因为每一层至多和相邻的上下层进行交互，因此功能的改变最多影响相邻的两层。可替换性。独立的层次设计容易被功能相似的模块替换。分层构架也有一些缺点，主要表现在：效率低。分层结构通常要比单层结构效率低，原因是有时高层过分依赖底层的服务，必须经过许多中间层进行数据传递。增加了一些不必要的工作。改变行为的连锁反应。设计者要建立不同合适粒度的抽象层次有一定困难。常见的分层架构模式有：客户端-服务器模型（Client-Server，C/S）。三层模型：用户表示层、业务逻辑层、数据层。14/82分层构架具有以下优点：97/8210.1架构设计四、常用的架构模式2.黑板模式

黑板模式的思想是，有一系列独立的模块，或者说是方案，这些方案能解决部分问题的一部分，这些方案进行协作，使得问题问题能够最终解决。这就像一群人在一块

黑板前，共同解决一个问题，根据当前问题解决的程度和状态，不同的人上前到黑板上解决他所能解决的部分，这样经过多人的协作，最终能够将问题解决。这就是

黑板模式这个名字的来历。黑板模式的实现分为三个主要的组件：黑板(Blackboard)，知识源(KnowledgeSource)和控制(Control)。。如图下所示。15/8210.1架构设计四、常用的架构模式2.黑板模98/82黑板模式16/82黑板模式99/8210.1架构设计四、常用的架构模式3.管道/过滤器模式

管道/过滤器模式构架中的每个构件都有一组输入和输出，构件读入数据流，经过处理产生输出数据。这个过程通过对输入流的变换及增量计算来完成，因此在输入流被完全使用掉之前，变产生了输出，这样的构件就是过滤器，而构件间的连接件就像是数据流传输的管道，它将数据从一个过滤器传到另一个过滤器。其中，过滤器必须是独立的实体，它不能与其他的过滤器共享数据。多个过滤器相连，可以形成过滤器链。而每个过滤器功能单一，可以单独修改，链中过滤器的排列顺序可以根据需求进行配置。17/8210.1架构设计四、常用的架构模式3.管道/100/82特征：每个过滤器构件是一个独立的部件，除了输入流和输出流外，过滤器之间互不影响，因此，过滤器之间不共享任何状态信息。每个过滤器对其上游或下游连接的过滤器是透明的，它的实现和使用不对链中的任何过滤器加以限制。如下图所示。管道/过滤器模式18/82特征：管道/过滤器模式101/82这种构架具有以下优点：可以创建具有良好隐蔽性和高内聚、低耦合的构件。设计者可以将整个系统的输入/输出行为看成是多个过滤器行为的简单合成。支持软件重用。通过添加新的过滤器或换掉旧的过滤器可以方便地维护系统，增强现有的系统功能。可以对一些如吞吐量、死锁等问题进行分析。支持并发过程。每个过滤器作为一个单独的任务完成，因此可与其他任务并行执行，有较高的并行处理效率。19/82这种构架具有以下优点：102/8210.1架构设计四、常用的架构模式4.中介模式

中介模式是构建带有隔离构件的分布式系统，系统通过远程服务调用进行交互。中介构件负责协调通信，包括转发请求、传送结果和异常等。这样的构架模式并不是一个整体的应用程序，而是若干个独立的和互操作的构件集合。通过将功能分割成独立的构件，系统具有可分割性和可扩展性，并具有较大的灵活性、可维护性和可变性。在中介构架中，系统可以添加、移动、交换、激活和定位构件服务，可以仅通过对象接口使用服务器中的应用程序对象，而不需要要知道对象的细节或其物理位置。20/8210.1架构设计四、常用的架构模式4.中介模103/8210.1架构设计四、常用的架构模式5.代理模式

代理模式由是客户机、服务器、代理程序、桥接、客户端代理和服务器端代理等构件组成的构架模式。客户机通过代理程序发送请求访问服务器功能。服务器为应用领域提供公共服务，或者向单一应用提供特定的功能服务。代理程序位于客户机和服务器之间，协调客户机和服务器之间的活动。21/8210.1架构设计四、常用的架构模式5.代理模104/82客户机端代理是客户机和代理程序之间的一个层。桥接是用来隐藏两个代理程序互相操作的细节的可选构件，它建立一个所有系统细节封装起来的层，便于系统在异构环境中运行。

通过使用代理模式，应用程序能够简单地通过向合适的对象发出消息调用访问分布式服务，而不是把重点放在低级进程间通信。另外，代理模式结构灵活，允许对对象动态改变、添加、删除和重定位。22/82客户机端代理是客户机和代理程序之间的一个层。桥接105/8210.1架构设计四、常用的架构模式6.MVC模式

MVC是模型-视图-控制器(Model-View-Control)的简称，是一种流行的系统开发框架。MVC把交互系统的组成分解成模型、视图、控制三种部件。如下图所示。23/8210.1架构设计四、常用的架构模式6.MVC106/82MVC模式24/82MVC模式107/82模型部件是软件所处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象，封装了问题的核心数据、逻辑和功能的计算关系，他独立于具体的界面表达和I/O操作。视图部件把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。控制部件是处理用户与软件交互操作的，其职责是控制提供模型中任何变化的传播，确保用户界面于模型间的对应联系；它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制。模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。25/82模型部件是软件所处理问题逻辑在独立于外在显示内容和108/82MVC的优点表现在以下几个方面：可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。26/82MVC的优点表现在以下几个方面：109/8210.1架构设计四、常用的架构模式7.PAC模式

PAC是表示-抽象-控制(Presentation-Abstraction-Control)的简称，它也是从数据模型及界面可视化的处理中提出的交互式系统构架。PAC将用户界面从数据管理中分离出来，从而降低了部件间的耦合度。如下图所示。27/8210.1架构设计四、常用的架构模式7.PAC110/8210.1架构设计四、常用的架构模式8.反射模式

反射模式是为动态地改变系统结构和行为提供相应机制的架构模式。它使系统维护了自身的信息，并使用这种信息来保持系统的可变性和可扩展性。一个反射系统在实现方面处于开放状态，以支持特定的结构和行为。

反射构架由两部分组成：元层次(MetaLevel)和基本层次(BaseLevel)。反射架构模式有以下优点：反射系统不直接修改源代码。系统更新简单易行。支持多种类型的变更。28/8210.1架构设计四、常用的架构模式8.反射模111/8210.1架构设计四、常用的架构模式8.反射模式

反射模式是为动态地改变系统结构和行为提供相应机制的架构模式。它使系统维护了自身的信息，并使用这种信息来保持系统的可变性和可扩展性。一个反射系统在实现方面处于开放状态，以支持特定的结构和行为。

反射构架由两部分组成：元层次(MetaLevel)和基本层次(BaseLevel)。29/8210.1架构设计四、常用的架构模式8.反射模112/8210.1架构设计四、常用的架构模式9.微核模式

微核是为应对需求变化所引起的系统更改而采取的一种架构设计。这种架构强调应用系统的自修改和自扩展能力，使系统的变化与更新不影响其核心功能及关键设计，从而降低为适应不断变化的需求必须进行的系统维护成本，使系统易于移植、扩展和集成不断出现的新构件，具有高度适应性并能满足客户特殊的定制需求。30/8210.1架构设计四、常用的架构模式9.微核模113/82微核模式由以下5个部分组成：内部服务器外部服务器适配器客户机微核31/82微核模式由以下5个部分组成：114/8210.2详细设计一、详细设计原则单一职责原则“开-闭”原则里氏代换原则合成复用原则依赖倒置原则接口隔离原则迪米特原则32/8210.2详细设计一、详细设计原则单一职责原则115/8210.2详细设计二、类设计类设计就是根据具体的实现语言将分析类转换成设计类，即按具体的实现语言，如Java、C#等，对分析类中的边界类、实体类和控制类细化已有方法、补充类属性，完成基本设计模型。类设计是将分析模型映射到设计模型最基础也是最重要的一项工作。以学生选课这个系统用例为例，并且假设我们使用java语言来开发。在建立分析模型的过程中，我们得到了如下图所示的实现了学生选课系统用例的分析模型类图。33/8210.2详细设计二、类设计类设计就是根据具体116/82学生选课用例分析模型34/82学生选课用例分析模型117/82分析类直接映射到设计类

上图所示的分析模型中，学生信息类已经非常接近设计类了，我们只需要将其属性和方法完善直接映射到设计类即可。如右图所示，学生信息类包含的属性有姓名、出生年月、性别、籍贯、入学时间、所属系别、班级、学号，同时为了与系统实现一致我们为其增加Id属性，包含的方法有设置和获取属性的方法，在这里我们分别为每个属性定义设置和获取的方法。学生信息设计类35/82分析类直接映射到设计类上图所示的分析模型中118/82分析类映射到多个设计类选课控制类映射到设计类系统选课栏目边界类映射到设计类36/82分析类映射到多个设计类选课控制类映射到设计类系统119/82分析模型映射设计模型

将分析类都映射到设计类后，将得到的设计类集中在一张图中，绘制出这些设计类之间的关系，就得到了设计模型。下面两图分别展示了学生选课系统用例在Web层的设计模型和，学生选课系统用例在Business层的设计模型。37/82分析模型映射设计模型将分析120/82学生选课web层设计模型38/82学生选课web层设计模型121/82学生选课Business层设计模型39/82学生选课Business层设计模型122/82对分析类的补充

将分析模型映射到设计模型后，得到了设计类及设计类之间的关系，至此得到了完整的静态设计模型。在比较复杂的系统设计中，静态图往往还不足以指导开发，这时有必要绘制设计类的交互图来说明这些类如何交互完成设计功能。下图展示了Business层学生选课设计类交互图。

40/82对分析类的补充将分析模型映射到设计模123/82Business层的学生选课设计类交互图41/82Business层的学生选课设计类交互图124/8210.2详细设计三、接口设计面向对象的一大优点是接口与实现的分离，它使得我们在考虑程序逻辑时可以完全不用考虑程序将怎样编写，而只考虑对象交互的接口。面向对象设计中，软件系统四通八达的神经网络正是通过接口设计来构建的。接口使对象之间相互传递消息从而构成整个系统。接口设计不良会导致消息处理出错从而造成系统功能失效接口决定了整个系统是否能正常运行。42/8210.2详细设计三、接口设计面向对象的一大优125/82为单个对象设计接口

典型的单个对象通常是封装某种算法，例如业务规则计算对象和业务逻辑处理对象。这些对象由于业务规则和业务逻辑的特殊使得它们很可能具有与众不同的方法。虽然这些对象没有抽象价值，但我们可以简单的为这些对象设计单独的接口，将它们的方法提取出来形成“接口实现”的形式为我们保留了替换实现类的可能。如10.2.3类设计一节中从分析类映射而来的处理选课业务逻辑的Business层的OfferuleControl这个类，他的方法是独特的，没有抽象价值，我们可以简单的将它的方法提取出来形成接口，接口设计结果如下图所示。43/82为单个对象设计接口典型的单126/82单个对象接口实现设计实例44/82单个对象接口实现设计实例127/82为具有相似性的对象设计接口在一个系统里会有许多具有相同或相似的行为模式。通常，这些对象承担着相同或相似的职责，即它们处理事情的办法都差不多，但处理的内容和具体过程可能不同。典型的具有相同或相似行为模式的对象是实体对象。实体对象主要作用是封装业务数据和对业务数据的操作方法。虽然实体对象封装的业务数据千差万别，但操作数据的方法无非增删改查。这是典型的行为相似内容不同的对象的例子。45/82为具有相似性的对象设计接口在一个系统里会有许多具有128/82具有相似行为对象接口设计实例46/82具有相似行为对象接口设计实例129/82为软件各层次设计接口

一个多层次的软件架构中，各层次之间的交互是错综复杂的。软件按层次分开的目的是为了使得各软件层职责清晰，各负其责。但是如果层次之间的交互过程没有很好的接口设计，软件分层带来的好处可能会完全丧失。如选课系统例子中，Web层与Business层之间的交互是由各种Action类和BussinessControl类来完成的。Action类的数量非常庞大，BussinessControl类的数量也很可观，在没有良好接口设计的情况下，WEB层与Business层之间的交互情况如下图所示错综复杂。47/82为软件各层次设计接口一个多层次的软件架130/82无良好接口设计的层次交互48/82无良好接口设计的层次交互131/82采用门面模式后的层次交互

采用门面模式来处理Web层和Business层之间的交互可以有效地减少交互的复杂度，使得层次之间保持清晰的关联。如下图所示，交互的复杂层度得到了有效的控制。49/82采用门面模式后的层次交互采用门面132/8210.3设计模式一、设计模式与分类设计模式提供一种解决问题的纲要设计，它描述普遍存在的在相互联系的构件中重复出现的结构，从而建立在一定的问题背景下通用的设计方案。设计模式通常被分成创建型、结构型、行为型三类。二、创建型设计模式1.工厂模式

工厂模式通过一个通用的工厂方法来生成对象，并专门负责将大量有共同接口的类实例化。工厂模式有简单工厂模式、工厂方法模式、抽象工厂模式三种。50/8210.3设计模式一、设计模式与分类设计模式提133/82简单工厂模式工厂方法模式51/82简单工厂模式工厂方法模式134/82抽象工厂模式52/82抽象工厂模式135/8210.3设计模式二、创建型设计模式2.单例模式单例(Singleton)模式又叫单件模式，它保证一个类仅有一个实例，并且提供一个对它的全局访问点。即单例类必须自己创建自己的唯一实例，保证没有其他实例可以被创建，并提供一个访问该实例的方法。单例结构如下图所示。53/8210.3设计模式二、创建型设计模式2.单例模136/82

单例模式的参与者只有一个，即Singleton。Singleton拥有一个私有的构造函数，确保无法通过new直接将其实例化。此外，该类还高含有一个静态私有成员变量instance和静态公有方法getInstance()。getInstance()负责检验并实例化Singleton，然后存储在静态成员变量instance中，确保只有一个实例被创建。单例模式54/82单例模式的参与者只有一个，即Sing137/8210.3设计模式三、结构型设计模式1.享元模式享元模式以共享的方式高效地支持大量的细粒度对象。享元对象能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态是存储在享元对象内部并且不会随环境改变而改变，因此内蕴状态可以共享。外蕴状态是随环境改变而改变的、不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态与内蕴状态是相互独立的。55/8210.3设计模式三、结构型设计模式1.享元模138/82享元模式所涉及的角色有：抽象享元(Flyweight)角色。具体享元(ConcreteFlyweight)角色。享元工厂(FlyweightFactory)角色。客户端(Client)角色。享元模式56/82享元模式所涉及的角色有：享元模式139/822.门面模式门面模式为一组复杂接口对象提供简单且特定的接口，以供外界使用。门面将子系统与客户及其它子系统分离，可以提供高子系统的独立性和可移植性。门面模式要求子系统的外部必须通过统一的接口与其内部进行通信，该模式提供一个高级的接口，使得子系统更易于使用。门面模式由三个角色组成：门面角色子系统角色客户角色。57/822.门面模式140/823．桥接模式桥接(Bridge)模式是将抽象(Abstraction)与实现(Implementation)脱耦，使得二者可以独立地变化。耦合是两个实体间的某种强关联，脱离就是去掉它们间的强关联，即将两个对象间的继承关系改为聚合关系。采用继承的情况下，具体实现依赖于抽象定义，抽象定义被看作是相对稳定的。而对于像多个维度变化激烈的对象来说，抽象定义也是不稳定的。这时候，如果想尽可能付出小的代价，获得最大的扩展，就可以采用桥接模式。桥接模式涉及的角色如下:58/823．桥接模式141/82抽象(Abstraction)对象：抽象对象给出的定义，并保存一个对象实现者(Implementor)对象的引用精化(RefinedAbstraction)抽象：扩展抽象对象，改变和修正父类对抽象的定义。实现者(Implementor)对象：给出实现者对象的接口，但不给出具体的实现方法。具体实现(ConcreteImplementor):给出实现者对象接口的实现方法。59/82抽象(Abstraction)对象：抽象对象给出的142/824．代理模式代理模式就是为其他对象提供一种代理以控制对这个对象的访问。就是，在一些情况下客户不想或者不能直接引用一个对象，而代理对象可以在客户和目标对象之间起到中介作用，去掉客户不能看到的内容和服务或者增添客户需要的额外服务。常见的代理：远程代理：为一个对象在不同的地址空间提供局部代理。虚拟代理：根据需要创建开销很大的对象。保护代理：控制对原始对象的访问，用于对象应该有不同的访问权限时。智能引用：取代了简单的指针，在访问对象时执行了一些附加操作。60/824．代理模式143/82如图所示，客户对象(Client)向一个作为接口的Subject发出请求，Subject接口的实施代理对象Proxy根据请求的种类，在适当的时候向RealSubject转发请求。代理模式的参与者如下：客户对象(Client)：向一个作为接口的Subject发出请求。代理对象(Proxy)：保存一个引用使其可以访问实体。抽象类(Subject)：定义实体目标对象RealSubject和代理对象Proxy的共用接口，这样就允许在任何使用RealSubject的地方都可以使用Proxy。实体目标对象(RealSubject)：定义代理对象Proxy所代表的实体。61/82如图所示，客户对象(Client)向一个作为接口的144/825．适配器模式适配器(Adapter)模式又叫包装(Wrapper)模式，指把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。适配器模式有类适配器和对象适配器两种。类适配器使用多重继承使一个接口与另一个接口进行匹配，类适配器模式如下图所示。由图可看出，类Adaptee类没有request方法，而客户期待这个方法。为了是客户能够使用Adaptee类，提供一个中间环节，即Adapter类，Adapter类实现了Target接口，并继承自Adaptee类，Adapter类的Request方法重新封装了Adaptee的specificRequest方法，实现了适配的目的。因为Adapter和Adaptee是继承关系，所以决定了这个适配器模式是类的。类适配器模式所涉及的参与者包括：目标(Target)：客户端所期待的接口。源(Adaptee)：需要适配的类。适配器(Adapter)：把源接口转换成目标接口，它必须是类。62/825．适配器模式145/82类适配器模式63/82类适配器模式146/82对象适配器依赖于对象组合，如下图所示。从图中可以看出：客户端需要调用request方法，而Adaptee没有该方法，为了使客户端能够使用Adaptee类，需要提供一个包装(Wrapper)类Adapter。这个类包装了一个Adaptee类的实例，从而将客户端与Adaptee衔接起来。由于Adapter与Adaptee是委派关系，从而决定了这个适配器模式是对象的。该适配器模式所涉及的参与者包括：目标(Target)：客户所期待的接口。源(Adaptee)：是需要适配的类。适配器(Adapter)：通过内部包装一个Adapter对象，把源接口转换成目标接口。64/82对象适配器依赖于对象组合，如下图所示。147/82对象适配器模式65/82对象适配器模式148/8210.3设计模式四、行为型设计模式1.调停者模式

通常，面向对象应用程序是由一组为了提供某种服务而彼此交互的对象组成，这组对象叫同事对象。当彼此引用的对象数量比较少时，此时对象之间就为直接交互。当对象的数量增加时，