结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象
一、代理模式
1. 概念
1）代理模式的定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介
2. 优缺点
1）优点
（1）代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
（2）代理对象可以扩展目标对象的功能
（3）代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度
2）缺点
（1）在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢
（2）增加了系统的复杂度
3. 模式结构
1）抽象主题（Subject）类：通过接口或抽象类声明真实主题和代理对象实现的业务方法
2）真实主题（Real Subject）类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象
3）代理（Proxy）类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，它可以访问、控制或扩展真实主题的功能
4. 应用场景
1）远程代理，这种方式通常是为了隐藏目标对象存在于不同地址空间的事实，方便客户端访问。例如，用户申请某些网盘空间时，会在用户的文件系统中建立一个虚拟的硬盘，用户访问虚拟硬盘时实际访问的是网盘空间
2）虚拟代理，这种方式通常用于要创建的目标对象开销很大时。例如，下载一幅很大的图像需要很长时间，因某种计算比较复杂而短时间无法完成，这时可以先用小比例的虚拟代理替换真实的对象，消除用户对服务器慢的感觉
3）安全代理，这种方式通常用于控制不同种类客户对真实对象的访问权限
4）智能指引，主要用于调用目标对象时，代理附加一些额外的处理功能。例如，增加计算真实对象的引用次数的功能，这样当该对象没有被引用时，就可以自动释放它
5）延迟加载，指为了提高系统的性能，延迟对目标的加载。例如，Hibernate 中就存在属性的延迟加载和关联表的延时加载
5. 拓展
这是静态代理，代理类中包含了对真实主题的引用，会有以下缺点
1）真实主题与代理主题一一对应，增加真实主题也要增加代理
2）设计代理以前真实主题必须事先存在，不太灵活
采用动态代理模式可以解决以上问题（Proxy.newProxyInstance（ClassLoader loader, Class<?>[] interfaces,InvocationHandler h）， 用一个类实现InvocationHandler做代理的附加操作，然后传入任意真实对象，非常灵活，在运行时生成代理对象，com.sun.proxy.$Proxy0是一般类名）
二、适配器模式
1. 概念
1）适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作
2）适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些
2. 优缺点
1）优点
（1）客户端通过适配器可以透明地调用目标接口
（2）复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类
（3）将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题
2）缺点
（1）对类适配器来说，更换适配器的实现过程比较复杂
3. 模式的结构
1）目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口
2）适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口
3）适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者
4. 应用场景
1）以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致
2）使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同
5. 扩展
1）适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口
三、桥接模式
1. 概念
1）桥接（Bridge）模式的定义如下：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度
2. 优缺点
1）优点
（1）由于抽象与实现分离，所以扩展能力强
（2）其实现细节对客户透明
2）缺点
（1）由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度
3. 模式的结构
1）抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用
2）扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法
3）实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用
4）具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现
4. 应用场景
1）当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时
2）当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
3）当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时
5. 拓展
1）在软件开发中，有时桥接（Bridge）模式可与适配器模式联合使用。当桥接（Bridge）模式的实现化角色的接口与现有类的接口不一致时，可以在二者中间定义一个适配器将二者连接起来
四、装饰模式
1. 概念
1）装饰（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式
2. 优缺点
1）优点
（1）采用装饰模式扩展对象的功能比采用继承方式更加灵活
（2）可以设计出多个不同的具体装饰类，创造出多个不同行为的组合
2）缺点
（1）装饰模式增加了许多子类，如果过度使用会使程序变得很复杂
3. 模式的结构
通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰模式的目标
1）抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象
2）具体构件（Concrete Component）角色：实现抽象构件，通过装饰角色为其添加一些职责
3）抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能
4）具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任
4. 应用场景
1）当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类
2）当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰模式却很好实现
3）当对象的功能要求可以动态地添加，也可以再动态地撤销时
5. 拓展
装饰模式所包含的 4 个角色不是任何时候都要存在的，在有些应用环境下模式是可以简化的，如以下两种情况
1）如果只有一个具体构件而没有抽象构件时，可以让抽象装饰继承具体构件
2）如果只有一个具体装饰时，可以将抽象装饰和具体装饰合并
五、外观模式
1. 概念
1）外观（Facade）模式的定义：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式
2）该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性
2. 优缺点
1）优点 —— 外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点
（1）降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类
（2）对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易
（3）降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象
2）缺点
（1）不能很好地限制客户使用子系统类
（2）增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”
3. 模式的结构
1）外观（Facade）角色：为多个子系统对外提供一个共同的接口
2）子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它
3）客户（Client）角色：通过一个外观角色访问各个子系统的功能
4. 应用场景
1）对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系
2）当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问
3）当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性
5. 拓展
1）在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题
六、享元模式
1. 概念
1）享元（Flyweight）模式的定义：运用共享技术来有効地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率
2. 优缺点
1）优点
（1）相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力
2）缺点
（1）为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性
（2）读取享元模式的外部状态会使得运行时间稍微变长
3. 模式的结构
1）抽象享元角色（Flyweight）:是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入
2）具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口
3）非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中
4）享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象
4. 应用场景
1）系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源
2）大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态
3）由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式
5. 拓展
在前面介绍的享元模式中，其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中，有时候会稍加改变，即存在两种特殊的享元模式：单纯享元模式和复合享元模式
1）单纯享元模式，这种享元模式中的所有的具体享元类都是可以共享的，不存在非共享的具体享元类
2）复合享元模式，这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的，它们就是复合享元对象。虽然复合享元对象本身不能共享，但它们可以分解成单纯享元对象再被共享
七、组合模式
1. 概念
1）组合（Composite）模式的定义：有时又叫作部分-整体模式，它是一种将对象组合成树状的层次结构的模式，用来表示“部分-整体”的关系，使用户对单个对象和组合对象具有一致的访问性
2. 优缺点
1）优点
（1）组合模式使得客户端代码可以一致地处理单个对象和组合对象，无须关心自己处理的是单个对象，还是组合对象，这简化了客户端代码
（2）更容易在组合体内加入新的对象，客户端不会因为加入了新的对象而更改源代码，满足“开闭原则”
2）缺点
（1）设计较复杂，客户端需要花更多时间理清类之间的层次关系
（2）不容易限制容器中的构件
（3）不容易用继承的方法来增加构件的新功能
3. 模式的结构
1）抽象构件（Component）角色：它的主要作用是为树叶构件和树枝构件声明公共接口，并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口；在安全式的组合模式中不声明访问和管理子类的接口，管理工作由树枝构件完成
2）树叶构件（Leaf）角色：是组合中的叶节点对象，它没有子节点，用于实现抽象构件角色中 声明的公共接口
3）树枝构件（Composite）角色：是组合中的分支节点对象，它有子节点。它实现了抽象构件角色中声明的接口，它的主要作用是存储和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法
4. 分类
组合模式分为透明式的组合模式和安全式的组合模式
1）透明方式：在该方式中，由于抽象构件声明了所有子类中的全部方法，所以客户端无须区别树叶对象和树枝对象，对客户端来说是透明的。但其缺点是：树叶构件本来没有 Add()、Remove() 及 GetChild() 方法，却要实现它们（空实现或抛异常），这样会带来一些安全性问题
2）安全方式：在该方式中，将管理子构件的方法移到树枝构件中，抽象构件和树叶构件没有对子对象的管理方法，这样就避免了上一种方式的安全性问题，但由于叶子和分支有不同的接口，客户端在调用时要知道树叶对象和树枝对象的存在，所以失去了透明性
5. 应用场景
1）在需要表示一个对象整体与部分的层次结构的场合
2）要求对用户隐藏组合对象与单个对象的不同，用户可以用统一的接口使用组合结构中的所有对象的场合
6. 拓展
1）如果对前面介绍的组合模式中的树叶节点和树枝节点进行抽象，也就是说树叶节点和树枝节点还有子节点，这时组合模式就扩展成复杂的组合模式了
参考网址
注：文章是经过参考其他的文章然后自己整理出来的，有可能是小部分参考，也有可能是大部分参考，但绝对不是直接转载，觉得侵权了我会删，我只是把这个用于自己的笔记，顺便整理下知识的同时，能帮到一部分人。
ps : 有错误的还望各位大佬指正,小弟不胜感激
3505
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
