一、 Adapter（适配器）——类对象结构型模式
1、 意图
将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不建兼容而不能一起工作的那些类可以一起工作
2、 别名
包装器（wrapper）
3、 动机
为复用而设计的工具箱类不能够被复用仅仅是仅仅是因为它的接口与专业应用领域所需要的接口不匹配
例如：工具箱里面已有图形对象的接口为Shape ，其里面有子类LineShape（绘画直线），PolygonShape（绘画多边形）
已有用于显示和编辑文本的TextView
问题：在TextView和Shape对象不能互换情况下，想复用TextView类来实现TextShape类，应该怎么做？
笨方法：获取工具箱的源代码，修改原先的TextView类，使它兼容Shape类
（缺点：不应该仅仅为了实现一个应用，工具箱就不得不采用一些与特定领域相关的接口）
方法一：定义一个类TextShape：同时继承Shape和TextView，将TextView实例作为TextShape的组成部分
总结：使用TextView的接口实现TextShape的方法，恰恰对应了Adapter模式的类和对象版本，所以，我们将TextShape成为适配器
4、 适用性
l 想使用一个已经存在的类，而它的接口不符合你的需求
l 想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作（不兼容的类）
l 想使用一些已经存在的子类。适配它的父类接口（这样就没不要对每一个进行子类化来匹配他们的接口
5、 优缺点：
l 优点
可以让任何两个没有关联的类一起运行。
提高了类的复用。
增加了类的透明度。
灵活性好。
l 缺点：
过多地使用适配器，会让系统非常零乱，不易整体进行把握。
（例如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。）
6、 相关模式：
1、 Bridge（桥接）模式，但是桥接的目的是将接口部分和实现部分分离，从而可以对它们较为容易也相对独立的加以改变，而Adapter则意味着改变一个已有对象的接口
2、 Decorator（装饰）模式增强了其他对象的功能而同时不改变它的接口，支持递归组合，对应用程序的透明性比适配器好
3、 Proxy（代理）模式，在不改变它的接口的条件下，为另外一个对象定义了一个代理
二、Bridge（桥接）——对象结构型模式
1、 意图
将抽象部分与它的实现部分分离，使它们可以独立地改变
2、 别名
Handle/Body
3、 动机
在抽象
例如：在一个用户界面工具箱中有一个可移植地Window抽象部分的实现，允许用户开发一些在Xwindow 和IBMDE Presentation Manager(PM)系统中都可以使用的应用程序
笨方法：运用继承机制，定义window抽象类和它的两个子类XWindow 和PM Window，由他们分别实现不同系统平台上的Window界面
（缺点：扩展Window抽象类使之适用于不同种类的窗口或新的系统平台很不方便，例如还要IconWindow，那还得必须新加XIconWindow和PMIconWindow
继承机制使得客户代码与平台相关，例如创建XWindow对象会将Window抽象和XWindow的实现部分绑定起来，使客户端程序依赖于XWindow的实现部分，很难讲客户代码移植到其他平台上）
桥接模式的方法：将Window抽象和的它实现部分分别放在独立的类层次结构中，其中的一个类层次结构针对窗口的接口（Window、IconWindow、TransientWindow），
另外一个独立的类层次结构针对平台相关的窗口实现部分，这个类层次结构的根类为WindowImp
总结：对Window之类的所有操作都是WindowImp接口中的抽象操作实现的，这就将窗口和抽象与系统平台相关的实现部分分离开来，因此，将Window与WindowImp之间的关系称为桥接
4、 适用性
l 不希望在抽象和他的实现部分之间有一个固定的绑定关系
l 想在多个对象间共享实现（引用计数），但同时要求客户并不知道这一点
l 对不同的抽象接口和实现部分组合，并分别对它们进行扩充
l 对一个抽象的实现部分的修改对应客户不产生影响，客户代码不必重新编译
5、 优缺点
l 优点：
(1)在很多情况下，桥接模式可以取代多层继承方案，多层继承方案违背了“单一职责原则”，复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它极大减少了子类的个数。
(2)桥接模式提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合“开闭原则”。
l 缺点：
桥接模式的使用会增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程。
三、 Composite（组合）——对象结构型模式
1、 意图
将对象组合成树形结构以表示“部分—整体”的层次结构，使得用户对单个的对象和组合对象的使用性具有一致性
2、 动机
用户可以组合多个简单组件以形成一些较大的组件，这些组件又可以组合成更大的组件，但要分别定义类和容器类，而组合模式使用递归组合，使用户不必对这些类进行区别）
3、 适用性
l 想表示对象的部分—整体层次结构
l 希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象
4、 优缺点
l 优点
1、高层模块调用简单
2、节点自由增加
l 缺点
在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则
温馨提示：依赖倒置原则——依赖于抽象，不能依赖于具体实现
四、 Decorator（装饰）——对象结构型模式
1、 意图
动态地给一个对象添加一些额外的职责
2、 别名
包装器（wrapper）（与Adapter（适配器）别名一样）
3、 动机
希望给某个对象而不是整个类添加一些功能，如果使用继承机制添加，从其他类继承边框特性可以被多个子类的实例使用，但是用户不能控制对组件添加边框的方式和时机，所以这个方法不够灵活，将组件嵌入另一个对象中，由这个对象添加边框
4、 适用性
l 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责
l 处理那些可以撤销的职责
l 当不能采用生成之类的方法进行扩充时
（例如1、可能有大量独立的扩展，为支持每一种组合将产生大量的之类，使得子类数目呈爆炸性增长；2、类定义被隐藏，或类定义不能用于生成子类）
5、 优缺点
l 优点：
装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
l 缺点：
多层装饰比较复杂。
五、 Façade（外观）——对象结构型模式
1、 意图
为子系统中的一组结构提供一个一致的界面，Façade模式定义了一个高层接口，使得这个一子系统更加容易使用
2、 动机
将一个系统划分成若干个子系统有利于降低系统的复杂性，外观对象为子系统中较一般的设施提供一个单一而简单的界面，使子系统间的通信和相互依赖关系达到最小
3、 适用性
l 要为一个复杂子系统提供一个简单的接口
l 客户程序与抽象的实现部分之间存在着很大的依赖性，外观模式将这个子系统与其他的分离，提高子系统的独立性和可移植性
l 需要构建一个层次结构的子系统时，外观模式定义子系统中每层的入口点，从而简化了它们之间的依赖关系
4、 优缺点
l 优点
1、减少系统相互依赖
2、提高灵活性
3、提高了安全性
l 缺点
符合开闭原则，如果要改东西很麻烦，继承重写都不合适
温馨提示：开闭原则——对扩展开放，对修改关闭
六、Flyweight（享元）——对象结构型模式
1、 意图
运用共享技术有效地支持大量细粒度的对象
2、 动机
由于类似文档编辑器使用对象来表示字符，这样会耗费大量内存，所以Flyweight（享元）模式对那些通常由于数据量太大而难以用对象来表示的概念或实体进行建模，flyweight是一个共享对象，可以同时在多个场景中使用，并且在每个场景中都可以作为一个独立的对象
3、 适用性
一个应用程序使用了大量的对象
完全由于使用大量的对象造成很大的存储开销
对象的大多数状态都可以变为外部状态
如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象
应用程序不依赖于对象标识。由于享元对象可以被共享，因此对于概念上明显有别的对象，标识测试将返回真值
4、 优缺点
l 优点：
大大减少对象的创建，降低系统的内存，使效率提高。
l 缺点：
提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱
5、 相关模式
Flyweight模式通常和组合模式结合起来，用共享叶节点的有向无环图实现一个逻辑上的层次结构
6、
七、Proxy（代理）——对象结构型模式
1、 意图
为其他对象提供一种代理以控制对这个对象的访问
2、 别名
Surrogate
3、 动机
用户可以对一个对象进行访问控制的原因是在需要这个对象时才对它进行创建和初始化
4、 适用性
（在需要比较通用和复杂的对象指针代替简单的指针的时候，使用代理模式）
1）、远程代理（Remote Proxy）为一个对象在不同的空间地址提供局部代表
2）、虚代理（Virtual Proxy）根据需要创建开销很大的对象
3）保护代理（Protection Proxy）控制对原始对象的访问。保护代理用于对象应该有不同的访问权限的时候（例如 在Choices操作系统[CIRM93]中KemelProxies为操作系统对象提供了访问保护）
4）、智能指引（Smart Reference）取代了简单的指针，它在访问对象时执行了一些附加操作，它典型用途包括：
对指向实际对象的引用计数，这样当该对象没有引用时，可以自动释放它
当第一次引用一个持久对象时，将它装入内存
在访问一个实际对象前，检查是否已经锁定了它，以确保其他对象不能改变它
5、 优缺点
l 优点
1、职责清晰
2、高扩展性
3、智能化。
l 缺点
1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
总结一、Adapter与Bridge
1、 两者共同特征
都给另外一个对象提供了一定程度的间接性，因而有利于系统的灵活性，都涉及从自身以为外的一个接口向这个接口转发请求
2、 Adapter
主要是为了解决两个已有接口之间不匹配问题，不考虑这些接口是怎么实现的，也不考虑他们各自会如何演化
3、 Bridge
对抽象接口与她的N个实现部分进行桥接，虽然是允许修改实现它的类，但它为用户提供稳定的接口，会在系统迭代中适应新的实现
总结二、Composite与Decorator
1、 Composite目的
构造类，使多个相关的对象能够以统一的方式处理，而多个对象可以被当作一个对象处理，它的重点不在装饰，而在于表示
2、 Decorator目的
不需要生成子类即可对对象添加职责，避免了静态实现所有功能组合，从而导致子类急剧增加
3、 两者互补性
在使用着两种模式进行设计时，无须定义新的类，仅需要将一些对象插接在一起既可构建应用。
总结三、Decorator与Proxy
1、 两者共同特征
都描述了怎样为对象提供一定程度上的间接引用，实现部分都保留了指向另一个对象的指针，它们向这个对象发送请求
2、 Proxy目的
当直接访问一个实体不方便或者不符合需求时，为这个实体提供一个替代者
3、 不同之Decorator
Decorator模式中，组件提供了部分功能，而N个装饰负责完成其他功能，适用于不能确定对象全部功能的情况
4、 不同之Proxy
Proxy模式中，实体定义了关键功能，Proxy提供或拒绝对它的访问，该模式强调的是代理与它的实体之间的关系，这种关系可以静态地表达
标签：桥接,对象,接口,实现,模式,一个,设计模式,结构型 来源： https://www.cnblogs.com/XiaoLiangSummary/p/15743502.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。