设计模式初步学习 02

接口隔离模式

1. 在组建构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
2. 典型模式
   • Facade
   • Proxy
   • Adapter
   • Mediator

Facade门面模式

系统间耦合的复杂度

动机（Motivation）

1. 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
2. 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

模式定义

为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。—《设计模式》GoF

结构（Structure）

要点总结

1. 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果—内部子系统的任何变化不会影响到Facade接口的变化。
2. Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
3. Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
4. Facade对外是松耦合，内部是高内聚。

Proxy代理模式

动机（Motivation）

1. 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。
2. 如何在不失去透明（一致性）操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。

模式定义

• 为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。 —《设计模式》GoF

结构（Structure）

• 代理类和实际类使用同样的接口，实际项目中，代理类的实现可能会很麻烦，比如分布式系统，需要使用网络协议来对其它机器上数据的访问。

要点总结

1. “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来许多问题，作为间接层的proxy对象便是解决这一问题的常用手段。
2. 具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write（读时共享写时复制）技术，有些可能对组件模块提供抽象代理层，在建构层次对对象做proxy。
3. Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

Adapter适配器模式

动机（Motivation）

1. 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
2. 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

模式定义

将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 —《设计模式》GoF

结构（Structure）

//目标接口（新接口）
class ITarget{
   
public:
    virtual void process()=0;
};

//遗留接口（老接口）
class IAdaptee{
   
public:
    virtual void foo(int data)=0;
    virtual int bar(