设计模式学习笔记——结构型模式
文章目录
- 适配器模式 Adapter
- 适用场景
- UML
- 桥接模式 Bridge
- 适用场景
- UML
- 组合模式 Composite
- 装饰模式 Decorator
- 外观模式 Facade
- 享元模式 Flyweight
- 代理模式 Proxy
适配器模式 Adapter
适用场景
- 希望使用某个类， 但是其接口与其他代码不兼容时， 可以使用适配器类。
UML
结构一：
适配器实现了其中一个对象的接口， 并对另一个对象进行封装。
结构二：
有些编程语言支持多继承，比如C++。适配器同时继承两个对象的接口，适配功能在重写的方法中完成。 最后生成的适配器可替代已有的客户端类进行使用。
eg:
Adapter::method() {specialData = convertToServiceFormat(data);return serviceMethod(specialData);
}
通过上面的分析可以看出来，适配器模式，是将某个对象封装到Adapter的内部，然后为被封装对象提供不同的接口。
桥接模式 Bridge
适用场景
- 如果你希望在几个独立维度上扩展一个类， 可使用该模式。
- 如果你想要拆分或重组一个具有多重功能的庞杂类 （例如能与多个数据库服务器进行交互的类）， 可以使用桥接模式。
- 如果你需要在运行时切换不同实现方法， 可使用桥接模式。
案例：
一个Shape类，派生出了Circle类和Square类。你希望对这样的类层次结构进行扩展以使其包含颜色， 所以你打算创建名为 红色Red和 蓝色Blue的形状子类。由于你已有两个子类， 所以总共需要创建四个类才能覆盖所有组合， 那就得派生出红色Circle+红色Square+蓝色Circle+蓝色Square。如果后续你想新增一个三角形形状，你需要增加两个子类，即红色三角形和蓝色三角形，再之后如果你想增加一个颜色，你需要增加三个子类。子类的个数会呈指数增长。
UML
- 抽象部分
Abstraction提供了高层控制逻辑，实际工作依赖于底层的实现Implementation。比如GUI程序的底层实际是调用了操作系统的API，此处的抽象部分就相当于GUI程序的主逻辑，底层的实现部分就相当于操作系统的API。
Abstraction::feature1(){...i.method1();...
}
Abstraction::feature2(){...i.method2();i.method3();
}
- 实现部分
Implementation声明了通用的接口，用于为高层提供功能。 - 具体实现
Concrete Implementation里包括了特定平台的代码 - 精确抽象
Refined Abstraction提供控制逻辑的变体(featureN)，与父类一样，也是依赖实现的接口与实现交互。 - 客户端
Client一般负责将某个抽象和某个实现连接起来，然后调用抽象的方法。abstraction.feature1();
像这样将高层抽象和具体实现分离开，两个部分可以分别演进而不会对另一方产生影响。至于为什么叫Bridge模式，大概主要是因为二者之间通过聚合关系关联到一起，这个聚合关系，就像是二者沟通的桥梁。
组合模式 Composite
将对象集合封装到Composite内部，为单元素和集合元素提供相同的接口，便于处理树形的逻辑结构。
装饰模式 Decorator
将对象封装到Decorator内部，为对象提供一个增强的接口。
外观模式 Facade
将子系统细节封装到Facade内部，为子系统提供一个简化的接口。
享元模式 Flyweight
将对象中不易变的大成员提取出来单独存储，而在对象内部只存储一个指向大成员的指针或者引用，以达到缩减内存占用的目的。
代理模式 Proxy
将对象封装到Proxy内部，为对象提供一个和对象相同的接口。