结构型设计模式——外观模式
文章目录
- 外观模式
- 结构
- 实现
- 特点
外观模式
**外观模式(Facade Pattern)**是一种使用频率非常高的结构型设计模式,它通过引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口,降低子系统与客户端的耦合度,且客户端调用非常方便。
简单来说,就是给很多复杂的子系统提供一个简单的上层接口,并在这些接口中包含用户真正关心的功能。
外观是一个对象,它为更大的代码 (例如类库) 提供了简化的接口。为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
外观模式又称为门面模式,它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现,通过引入一个新的外观角色可以降低原有系统的复杂度,同时降低客户类与子系统的耦合度。
结构
外观模式包含如下两个角色:
- 外观(Facade):提供了一种访问特定子系统功能的便捷方式, 其了解如何重定向客户端请求,知晓如何操作一切活动部件。
- 附加外观 (Additional Facade):可以避免多种不相关的功能污染单一外观, 使其变成又一个复杂结构。 客户端和其他外观都可使用附加外观。
- 复杂子系统 (Complex Subsystem):由数十个不同对象构成。 如果要用这些对象完成有意义的工作, 你必须深入了解子系统的实现细节, 比如按照正确顺序初始化对象和为其提供正确格式的数据。子系统类不会意识到外观的存在, 它们在系统内运作并且相互之间可直接进行交互。
- 客户端 (Client):使用外观代替对子系统对象的直接调用。
实现
// 乐可系统classCokeSystem{public:voidimmitCoke(){cout<<"狮吼炮原料<可乐>已经注入完毕..."<<endl;}};// 能量转换系统classEnergySystem{public:voidenergyConvert(){cout<<"已经将所有的可乐转换为了能量..."<<endl;}};// 目标锁定系统classAimLockSystem{public:voidaimLock(){cout<<"已经瞄准并且锁定了目标..."<<endl;}};// 加农炮发射系统classCannon{public:voidcannonFire(){cout<<"狮吼炮正在向目标开火..."<<endl;}};// 风来炮稳定系统classWindCannon{public:voidwindCannonFire(){cout<<"发射风来炮抵消后坐力稳定船身..."<<endl;}};// 上层接口classLionCannon{public:LionCannon(){m_coke=newCokeSystem;m_energy=newEnergySystem;m_aimLock=newAimLockSystem;m_cannon=newCannon;m_windCannon=newWindCannon;}~LionCannon(){deletem_coke;deletem_energy;deletem_aimLock;deletem_cannon;deletem_windCannon;}// 瞄准并锁定目标voidaimAndLock(){m_coke->immitCoke();m_energy->energyConvert();m_aimLock->aimLock();}// 开炮voidfire(){m_cannon->cannonFire();m_windCannon->windCannonFire();}private:CokeSystem*m_coke=nullptr;EnergySystem*m_energy=nullptr;AimLockSystem*m_aimLock=nullptr;Cannon*m_cannon=nullptr;WindCannon*m_windCannon=nullptr;};intmain(){// 发射狮吼炮LionCannon*lion=newLionCannon;lion->aimAndLock();lion->fire();deletelion;return0;}外观模式是一个很重要、平时也经常使用的设计模式,其核心思想就是化繁为简,封装底层逻辑,将使用者真正关心的功能通过上层接口呈现出来。
特点
主要优点
- **它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。**通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
- 它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
- **一个子系统的修改对其他子系统没有任何影响,**而且子系统内部变化也不会影响到外观对象。
主要缺点
- 不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
- 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了**开闭原则****。**
适用环境
- 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
- 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦,从而提高子系统的独立性和可移植性。
- 在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。
