结构型模式
解决设计类结构时遇到的问题
一、Adapter
1.需求
- 想要复用
- 已有组件中的逻辑
- 无法直接使用
- 已有组件的接口 与 正在使用的接口 不同
2.解决思路
- 接口转换
- 调用已有组件，实现现有接口
- 增加中间层
- 创建新的类，封装接口转换逻辑
3.代码示例
4.模型图
二、Bridge
1.需求
- 属性是扩展点
- 需要修改类结构
- 行为逻辑是扩展点
- 需要修改方法的实现代码
2.解决思路
- 抽象类
- 通过类继承，解决属性的扩展问题
- 分离行为的实现
- 定义抽象行为类
- 实现各种行为
- 每种行为类都要继承自抽象行为类
- 桥接
- 将抽象行为，组合到抽象类中，将各自变化的属性和行为衔接起来
3.代码示例
bridge负责自己的属性变化，行为逻辑就委托给behavior来实现
4.模型图
三、Composite
1.需求
- 容器和元素的接口不同
- 需要先判断类型，然后分别调用不同的接口
2.解决思路
- 组合成树形结构
- 描述 <整体-部分> 这个结构
- 统一接口
- 使用时无需判断，保持一致性
3.代码示例
将容器对象的操作递归到基本对象上
4.模型图
四、Decorator
1.需求
- 属性是扩展点
- 需要修改类结构
- 行为逻辑需要扩展附加功能
- 需要在方法内增加代码
- 扩展的附加功能个数很多
- 需要针对每种排列组合，扩展相应的类，造成类爆炸
- 有点像AOP
- 在指定方法（前/后）添加代码
2.解决思路
- 抽象类
- 通过类继承，解决属性的扩展问题
- X功能附加到Y对象
- 描述一个装饰类，专门用于将功能附加到指定对象上
- 装饰类设计
- 对外表现为原始类，因此要继承原始类；对内要附加的对象类型是原始类，所以要组合一个原始类对象；由于是对指定对象进行附加，所以类的方法全部由指定对象来实现
- 抽象装饰类
- 附加功能是变化点，所以需要继承机制，描述多种附加功能
3.代码示例
4.模型图
五、Facade
1.需求
- 子系统复杂
- 使用前，需要了解子系统的全部细节（好烧脑）
2.解决思路
- 最小知识原则
- 与了解子系统的人沟通，说明自己的需求，约定一个够自己使用的接口
- 实现接口
- 子系统人员提供一个类，实现该接口（这个类就像子系统的外观，所以叫外观类）
3.代码示例
外观类为子系统提供一个简单的对外接口
4.模型图
六、Proxy
1.需求
- 类的某些参数需要固定或隐藏
- 如：系统对外的邮箱，给各个组件提供邮件服务，但密码要隐藏；再比如：现实中，跟经纪人谈商业合作，不直接接触本人
- 无法直接使用的类
- 如：WebService，无法直接使用远程服务器上的对象
2.解决思路
- 增加中间层
- 解耦依赖关系
3.代码示例
把原始对象包裹一下
4.模型图
七、Flyweight
1.需求
- 大量相似的对象
- 消耗过多的内存
2.解决思路
- 共用相同的部分
- 单另存储一份数据，所有对象引用它
- 识别相同的部分
- 内蕴状态：不随环境改变的属性
- 识别不同的部分
- 外蕴状态：随环境改变的属性
- 管理共享的对象
- 描述一个享元工厂，共享部分用键值对来存储，根据键返回享元对象
3.代码示例
4.模型图
1.总的思路：不从头设计类结构，尽量复用现有逻辑
2.