“接口隔离”模式

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

典型模式：

1、Facade

2、Proxy

3、Adapter

4、Mediator

Facade 门面模式

系统间耦合的复杂度

在这里插入图片描述

**动机（Motivation）**💡：

上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

**问题思考（Consider）**🤔：

如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

C++执行代码：

Facade.cpp

#include <iostream>
class SubsystemA
{
public:
    void suboperation()
    {
        std::cout << "Subsystem A method" << std::endl;
    }
};

class SubsystemB
{
public:
    void suboperation()
    {
        std::cout << "Subsystem B method" << std::endl;
    }
};

class SubsystemC
{
public:
    void suboperation()
    {
        std::cout << "Subsystem C method" << std::endl;
    }
};

class Facade
{
public:
    Facade() : subsystemA(), subsystemB(), subsystemC() {}

    void operation1()
    {
        subsystemA->suboperation();
        subsystemB->suboperation();
    }

    void operation2()
    {
        subsystemC->suboperation();
    }

private:
    SubsystemA* subsystemA;
    SubsystemB* subsystemB;
    SubsystemC* subsystemC;
};


int main()
{
    Facade* facade = new Facade();

    facade->operation1();
    facade->operation2();
    delete facade;

    return 0;
}

Facade1.cpp

#include <iostream>
using namespace std;

//子系统：牛奶系统、能量转换系统、锁定目标系统、炮弹发射系统、雷电炮加强声势
//这些子系统都可以独立工作，并且都提供了给外部调用的接口

//牛奶系统
class MilkSystem {
public:
	void immitMilk() {
		cout << "牛奶炮原料<牛奶>已经注入完毕..." << endl;
	}
};

//能量转换系统
class EnergySystem {
public:
	void energyConvert() {
		cout << "已经将所有牛奶全部吸收并且转换成能量" << endl;
	}
};

//锁定目标系统
class AimLockSystem {
public:
	void aimLock() {
		cout << "已经瞄准并且锁定了目标..." << endl;
	}
};

//炮弹发射系统
class Cannon {
public:
	void cannonFire()
	{
		cout << "朝着目标，全力开炮..." << endl;
	}
};

//雷电炮加强声势
class ThunderCannon {
public:
	void thunderCannonFire() {
		cout << "雷电炮加强声势..." << endl;
	}
};

//上层接口
class MilkCannon {
public:
	MilkCannon() {
		m_milk = new MilkSystem;
		m_energy = new EnergySystem;
		m_aimLock = new AimLockSystem;
		m_cannon = new Cannon;
		m_thunderCannon = new ThunderCannon;
	}
	~MilkCannon() {
		delete m_milk;
		delete m_energy;
		delete m_aimLock;
		delete m_cannon;
		delete m_thunderCannon;
	}
	//瞄准并锁定目标
	void aimAndLcok() {
		m_milk->immitMilk();
		m_energy->energyConvert();
		m_aimLock->aimLock();
	}
	//开炮
	void fire() {
		m_cannon->cannonFire();
		m_thunderCannon->thunderCannonFire();
	}
private:
	MilkSystem* m_milk = nullptr;
	EnergySystem* m_energy = nullptr;
	AimLockSystem* m_aimLock = nullptr;
	Cannon* m_cannon = nullptr;
	ThunderCannon* m_thunderCannon = nullptr;
};

int main() {
	MilkCannon* milkCannon = new MilkCannon;
	milkCannon->aimAndLcok();
	milkCannon->fire();
	delete milkCannon;
	return 0;
}

模式定义

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

----《设计模式》GoF

结构（Structure）

在这里插入图片描述

要点总结

从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。

Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。

Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。

Proxy 代理模式

**动机（Motivation）**💡：

在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。

**问题思考（Consider）**🤔：

如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。

代理模式.cpp

使用代理模式，不能改变所代理的类的接口，使用代理模式的目的是为了加强控制

#include <iostream>
using namespace std;
//抽象支付类
class PayMent {
public:
	virtual void payment() = 0;//支付
	virtual ~PayMent() {}
};

//现金支付
class Cash :public PayMent {
public:
	Cash(int money) {
		m_money = money;
	}
	void payment() override {
		cout << "准备结账..." << endl;
		cout << "支付金额："<<m_money <<"元" << endl;
	}
private:
	int m_money = 0;
};

//微信支付
class WeiXin :public PayMent {
public:
	WeiXin(int money) {
		m_isPay = true;
		m_cash = new Cash(money);
	}
	~WeiXin() {
		if (m_cash != nullptr) {
			delete m_cash;
		}
	}
	//判断是否已经支付了
	bool isPay() {
		return m_isPay;
	}
	void payment()override {
		if (isPay()) {
			cout << "微信支付..." << endl;
			m_cash->payment();
		}
	}
private:
	bool m_isPay = false;
	Cash* m_cash = nullptr;
};

int main() {
	//现金支付
	PayMent* pay = new Cash(10);
	pay->payment();
	delete pay;
	cout << "===================================" << endl;
	//微信支付
	pay = new WeiXin(10);
	pay->payment();
	delete pay;
	return 0;
}

在这里插入图片描述

模式定义

为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。

----《设计模式》GoF

结构（Structure）

在这里插入图片描述

要点总结

“增加一层间接层”是软件系统对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是这一问题的常用手段。

具体proxy设计模式的实现方法，实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做proxy。

Proxy并不一定要求保持接口完整的一致性，只要能过实现间接控制，有时候损及一些透明性是可以接受的。

Adapter 适配器

**动机（Motivation）**💡：

在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。

**问题思考（Consider）**🤔：

如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

Adapter.cpp

#include <iostream>
using namespace std;
class Foreigner {
public:
	virtual string Introduction() = 0;
	void recvMessage(string msg) {
		cout << "中国导游说:" << msg << endl;
	}
	virtual ~Foreigner() {}
};

//美国人
class American :public Foreigner {
public:
	string Introduction() override {
		return string("我来自美国...");
	}
};

//法国人
class French :public Foreigner {
public:
	string Introduction() override {
		return string("我来自法国...");
	}
};

//导游
class Guide {
public:
	void recvMessage(string msg) {
		cout << msg << endl;
	}
	string sendMessage() {
		return string("欢迎来这里参观中国的名胜古迹...");
	}
};

//抽象适配器类
class AbstractAdapter {
public:
	AbstractAdapter(Foreigner* foreigner) :m_foreigner(foreigner) {};
	virtual void translateToGuide() = 0;
	virtual void translateToHuman() = 0;
	virtual ~AbstractAdapter() {}
protected:
	Guide m_guide;
	Foreigner* m_foreigner = nullptr;
};

//英语适配器
class EnglishAdapter : public AbstractAdapter {
public:
	//继承构造函数
	using AbstractAdapter::AbstractAdapter;
	void translateToGuide() override {
		string msg = m_foreigner->Introduction();
		// 翻译并将信息传递给导游对象
		m_guide.recvMessage("美国人说:" + msg);
	}
	void translateToHuman() override {
		//接受导游的信息
		string msg = m_guide.sendMessage();
		//翻译并将导游的话转发给导游
		m_foreigner->recvMessage("美国人," + msg);
	}
};

//法语适配器
class FrenchAdapter :public AbstractAdapter {
public:
	using AbstractAdapter::AbstractAdapter;
	void translateToGuide() override {
		string msg = m_foreigner->Introduction();
		//翻译并将信息传递给导游对象
		m_guide.recvMessage("法国人说：" + msg);
	}
	void translateToHuman() override {
		//接受导游的信息
		string msg = m_guide.sendMessage();
		//翻译并将导游的话转发给法国人
		m_foreigner->recvMessage("法国人，" + msg);
	}
};

int main() {
	Foreigner* human = new American;
	EnglishAdapter* american = new EnglishAdapter(human);
	american->translateToGuide();
	american->translateToHuman();
	delete human;
	delete american;

	human = new French;
	FrenchAdapter* french = new FrenchAdapter(human);
	french->translateToGuide();
	french->translateToHuman();
	delete human;
	delete french;

	return 0;
}

在这里插入图片描述

模式定义

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

要点总结

Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用，类库迁移等方面非常有用。

GoF 23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用。对象适配器采用“对象组合“的方式，更符合松耦合精神。

Adapter模式可以实现的非常灵活，不必拘泥于GoF 23中定义的两种结构。例如：完全可以将Adapter模式中的”现存对象”作为新的接口方法参数，来达到适配的目的。

Mediator 中介者

**动机（Motivation）**💡：

在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。

在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。

中介者模式可以减少对象之间混乱无序的依赖关系，从而使其耦合松散，限制对象之间的直接交互，迫使它们通过一个中介者对象进行合作。[来自爱编程的大丙https://subingwen.cn/design-patterns/mediator/]
推荐看爱编程的大丙的C++设计模式，写得真的很棒！

/*
 * C++ Design Patterns: Mediator
 * Author: Jakub Vojvoda [github.com/JakubVojvoda]
 * 2016
 *
 * Source code is licensed under MIT License
 * (for more details see LICENSE)
 *
 */

#include <iostream>
#include <vector>
#include <string>

class Mediator;

/*
 * Colleague classes
 * each colleague communicates with its mediator whenever
 * it would have otherwise communicated with another colleague
 */
class Colleague
{
public:
  Colleague( Mediator* const m, const unsigned int i ) : 
    mediator( m ), id( i ) {}
  
  virtual ~Colleague() {}
  
  unsigned int getID()
  {
    return id;
  }
  
  virtual void send( std::string ) = 0;
  virtual void receive( std::string ) = 0;

protected:
  Mediator *mediator;
  unsigned int id;
};

class ConcreteColleague : public Colleague
{
public:
  ConcreteColleague( Mediator* const m, const unsigned int i ) : 
    Colleague( m, i ) {}
  
  ~ConcreteColleague() {}
  
  void send( std::string msg );
  
  void receive( std::string msg )
  {
    std::cout << "Message '" << msg << "' received by Colleague " << id << std::endl;
  }
};

/*
 * Mediator
 * defines an interface for communicating with Colleague objects
 */
class Mediator
{
public:
  virtual ~Mediator() {}
  
  virtual void add( Colleague* const c ) = 0;
  virtual void distribute( Colleague* const sender, std::string msg ) = 0;

protected:
  Mediator() {}
};

/*
 * Concrete Mediator
 * implements cooperative behavior by coordinating Colleague objects
 * and knows its colleagues
 */
class ConcreteMediator : public Mediator
{
public:
  ~ConcreteMediator()
  {
    for ( unsigned int i = 0; i < colleagues.size(); i++ )
    {
      delete colleagues[ i ];
    }
    colleagues.clear();
  }
  
  void add( Colleague* const c )
  {
    colleagues.push_back( c );
  }
  
  void distribute( Colleague* const sender, std::string msg )
  {
    for ( unsigned int i = 0; i < colleagues.size(); i++ )
    {
      if ( colleagues.at( i )->getID() != sender->getID() )
      {
        colleagues.at( i )->receive( msg );
      }
    }
  }

private:
  std::vector<Colleague*> colleagues;
};

void ConcreteColleague::send( std::string msg )
{
  std::cout << "Message '"<< msg << "' sent by Colleague " << id << std::endl;
  mediator->distribute( this, msg );
}


int main()
{
  Mediator *mediator = new ConcreteMediator();
  
  Colleague *c1 = new ConcreteColleague( mediator, 1 );
  Colleague *c2 = new ConcreteColleague( mediator, 2 );
  Colleague *c3 = new ConcreteColleague( mediator, 3 );
  
  mediator->add( c1 );
  mediator->add( c2 );
  mediator->add( c3 );
  
  c1->send( "Hi!" );
  c3->send( "Hello!" );
  
  delete mediator;
  return 0;
}

模式定义

用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。

----《设计模式》GoF

要点总结

将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。

随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。

Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。