设计模式学习笔记——结构型模式
文章目录
- 适配器模式 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内部,为对象提供一个和对象相同的接口。