Facade
门面模式
为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。
解决什么问题
解决系统间耦合的问题
下图中方案A的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战
如何简化外部客户程序和系统将的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦
结构
要点总结
- 从客户程序的角度看，Facade模式简化了整个组件系统的接口，对于组件内部与组件外部客户程序来说，达到一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
- Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
- Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
Proxy
代理模式
为其他对象提供一种代理以控制（隔离、使用接口）对这个对象的访问。
解决什么问题
在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要的安全控制，或者需要进程外的访问等），直接访问会给使用者或者系统结构带来很多麻烦。
如何在不失去透明操作对象的同时来控制/管理这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。
结构
要点总结
- “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常用手段。
- 具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做proxy。
- Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。
示例
class ISubject {
public:
virtual void process();
// ...
};
class RealSubject : public ISubject {
public:
virtual void process() {
// ...
}
};
class ClientApp {
private:
ISubject* subject;
public:
ClientApp() {
// ...
subject = new RealSubject();// 由于某些原因 我们做不到直接生成RealSubject
// ...
}
void DoWork() {
// ...
subject->process();
}
};
class ISubject {
public:
virtual void process();
// ...
};
class SubjectProxy : public ISubject {
private:
// RealSubject* ...
public:
virtual void process() {
// 对RealSubject的间接访问
// ...
}
};
class ClientApp {
private:
ISubject* subject;
public:
ClientApp() {
// ...
subject = new SubjectProxy();
// ...
}
void DoWork() {
// ...
subject->process();
}
};
Adapter
适配器
将一个类的接口转化成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
解决什么问题
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
如何应对这种“迁移的变化”？如何既能利用现有对象的良好表现，同时又能满足新的应用环境所要求的的接口？
结构
示例
// 目标接口（新接口）
clas ITarget {
public:
virtual void Process() = 0;
};
// 遗留接口（老接口）
class IAdaptee {
public:
virtual void foo(int data) = 0;
virtual int bar() = 0;
};
class OldClass : public IAdaptee {
// ...
}
class Adapter : public ITarget {
protected:
IAdaptee* pAdaptee;
public:
Adapter(IAdaptee* pAdaptee) {
this->pAdaptee = pAdaptee;
}
virtual void Process() {
// 使用遗留接口
// ...
pAdaptee->foo(data);
// ...
}
};
int main() {
IAdaptee* pAdaptee = new OldClass();
ITarget* pTarget = new Adapter(pAdaptee);
pTarget->Process();
}
Mediator
中介者
用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显示的相互引用（编译时依赖--->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。
解决什么问题
在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将会面临不断地变化。
在这种情况下，我们可以使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
结构
要点总结
- 将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
- 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
- Facade模式是解耦系统间（单向）的对象关联关系。Mediator模式是结构系统内各个对象之间（双向）的关联关系。