【大话设计模式】--结构型模式

本文主要是介绍【大话设计模式】--结构型模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在结束创建型模式的总结之后，继续结构型模式的学习总结。

结构型模式是？

在软件工程中结构型模式是设计模式，通过了解元件间的关系，以简化设计。结构型模式涉及到如何组合类和对

象以获得更大的结构。结构型模式采用继承机制来组合结构或实现，不是对接口和实现进行组合，而是描述了如何对

一些对象进行组合，从而实现新功能的一些方法。因为可以在运行时刻改变对象组合关系，所以对象组合方式具有更

大的灵活性，而这种机制用静态类组合是不可能实现的。

我把这些属于结构型模式的设计模式们小小的分了一下类，为了更方便的区分他们之间的关系。如下图：

根据此图，再对他们进行一一细说：

装饰模式 & 组合模式

因为他们太孤独了，所以把他们勉强凑一家，一起说！

装饰模式——就是为了漂亮

装饰模式就是动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活。

它的UML类图如下：

由定义和UML图可知，装饰模式是利用SetComponent来对对象进行包装的。每个具体的装饰对象的实现就和如何

使用这个对象那个分离开了，每个装饰对象只关系自己的功能，不需要关心如何被添加到对象链当中的。

举个小例子说明一下：设计师设计出来搭配的衣服，只需要照着穿就行了，不用管人家搭配的具体过程。

装饰模式的优点是它能把类中的装饰功能从类中扔掉，简化了原有重复的类；还能有效地把类的核心职责和装饰

功能区分开，还可以去除相关类中重复的装饰逻辑。

组合模式——树形结构

组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的

使用具有一致性。它的UML类图如下：

其中的：

Component是组合中的对象声明接口，在适当情况下，实现所有类共有接口的默认行为。声明一个接口用于访问

和管理Component的子部件。

Leaf在组合中表示叶节点对象。注：叶节点没有子节点。

Composite定义有枝节点行为，用来存储子部件，在Component接口中实现与子部件有关的操作，比如增加Add和

删除Remove。

从实例看，组合模式就是一个树形结构，从根部开始以增加枝节点的方式一直往上蔓延，到叶节点结束。整个过

程就是一颗树的生长过程，是很漂亮的一种设计模式。

它的优势是体现部分与整体层次的结构，并且可以忽略掉组合对象与单个对象的不同；基本对象可以被组合成更

复杂的组合对象，而这个组合对象又可以被组合，这样不断地递归下去，客户代码中，任何用到基本对象的地方都可

以使用组合对象了。

中介

为什么把适配器、代理和外观统一到中介这块，因为他们都需要经过第三方，只是各个情况有所不同，下边就不

同点进行一下说明。

适配器模式——离不开翻译

Adapter模式将一个类的接口转换成客户希望的另一个接口。它使得原本由于接口不兼容而不能一起工作的那些

类可以一起工作。它的目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些

现存的类，但是接口又与复用环境要求不一致的情况。它的UML类图如下：

如书上的例子，姚明刚到火箭的时候英语肯定不熟练，但是通过翻译就能知道教练的指令了。而这个翻译就是这

的Adapter，姚明就是Adaptee。

代理模式——媒婆

代理模式为其他对象提供一种代理，以控制对这个对象的访问。它的UML类图如下：

真心觉得书上的例子太经典，本来一个男同学喜欢一个女同学，非要第三个人给传递情书，结果姑娘跑了吧！所

以追姑娘这事还是自己亲自来的好。这个实例中，中间的那个人就是那个代理，帮助男主给女主情书，最后替代了男

主。

代理模式分为三种：

1、远程代理：为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事

实。

2、虚拟代理：根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。

3、安全代理：用来控制真实对象访问时的权限。

对这三种代理理解较浅，在接下来的学习中加深吧。

外观模式——中间平台

外观模式是为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统

更加容易使用。它的UML类图如下：

书上说外观模式和经典三层的概念相类似，就是借助中间平台，把客户端和具体的子系统分离开来，减少依赖。

现在我们正在做的云平台就是非常典型的一个实例。这个云平台就是这类的Facade，它管理着我们下边隶属的子

系统：基础系统，评教系统，考试系统等。

外观模式在什么时候使用？

1、在设计初期，有意识的将不同的两个层分解。

2、在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观可以提供一个简单的接口，减少

依赖。

3、在维护阶段，新增Facade类提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade

对象交互，Facade与遗留代码交互所有复杂的工作。

共享

从桥接模式和享元模式的实例可以看出，它们都有分享、共享的特性，不信你就来看看！

桥接模式——share

书上刚开始引入桥接模式的时候是以大鸟玩手机游戏，可是却不能跟小菜share，所以引入桥接模式。

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

定义结合例子说明一下，也就是说：将手机中游戏分离出来，然后无论什么品牌的手机都可以share这个游戏，

这样的话，小菜就不用眼巴巴在旁边看着大鸟打游戏了。不仅是游戏，手机中的照相，播放器，通讯录，QQ都可以分

离出来，看现在的手不都有这些基础的功能了吗？

来看看桥接模式的UML类图：

桥接模式遵循原则合成/聚合复用原则，此原则会在设计原则里具体说明。

享元模式——共享

享元模式主要运用共享的技术有效地支持大量细粒度的对象（细粒度指将模型中的对象加以细分，得到更科学合

理的对象模型）。它的UML类图如下：

上图中，FlyweightFactory是一个享元工厂，用来创建并管理Flyweight对象。主要作用是确保合理共享

Flyweight。

Flyweight是所有具体享元类的超类或接口，通过这个接口，Flyweight可以接受并作用于外部状态。

ConcreteFlyweight继承Flyweight超类或实现Flyweight接口，并为内部状态增加存储空间。

UnsharedConcreteFlyweight指那些不需要共享的Flyweight子类。

还是拿云平台举例，无论是哪一个子系统都需要大量的学生，教师，课程的数据，所以我们把这些数据都导入到

基础系统里边，这样无论是评教还是考试都可以从基础里边调用数据，就不用专门在评教和考试系统中重新建数据库

存储专门存储这些数据。但是因为评教和考试系统毕竟不是同一个系统，所以它们的功能会有所不同，这些不同的地

方就是不需要共享的UNshareConcreteFlyweight。