设计模式-06 设计模式-Facade Pattern门面模式

1.定义

门面模式（Facade Pattern）定义

门面模式为一个子系统提供了一个统一的接口，从而简化了对该子系统中多个组件的访问。

它通过为客户端提供一个单一的入口点来隐藏子系统的复杂性，从而使客户端能够以更简单的方式与子系统交互。

门面模式结构

Facade（门面）：这是一个包装类，提供了一个简化的接口来访问子系统。
Subsystem（子系统）：这是门面模式表示的实际子系统。它由多个组件组成，这些组件共同提供一些功能。

门面模式工作原理

客户端通过门面类与子系统进行交互。门面类将客户端的请求委派给适当的子系统组件，并处理子系统之间的交互。

通过这种方式，客户端不必了解子系统的内部复杂性，从而简化了与子系统的交互。

2.内涵

门面模式（Facade Pattern）的内涵：

抽象和封装：门面模式抽象了子系统的复杂性，为客户端提供了一个简化的接口。它封装了子系统中的组件，使客户端不必了解这些组件的内部工作原理。
解耦：门面模式将客户端与子系统解耦，使客户端和子系统可以独立开发和维护。这提高了代码的可维护性和可测试性，因为更改子系统不会影响客户端代码。
灵活性：门面模式提供了灵活性，允许在不影响客户端代码的情况下更改子系统。当需要添加或删除组件或更改子系统的行为时，这非常有用。
控制和安全性：门面模式可以充当控制和安全层，仅允许经过授权的客户端访问子系统。它还可以隐藏子系统中的敏感信息或操作。
可扩展性：门面模式支持可扩展性，允许在需要时轻松地添加新的子系统或功能。客户端代码不需要修改，只需更新门面类即可。

门面模式的内涵还包括：

单一职责原则：门面类只负责提供一个简化的接口，而子系统负责实现实际功能。这符合单一职责原则，使代码更易于理解和维护。
依赖反转原则：门面模式通过将依赖关系反转到门面类来实现依赖反转原则。客户端依赖于门面类，而不是具体的子系统组件。
开放-封闭原则：门面模式遵循开放-封闭原则，允许在不修改客户端代码的情况下扩展子系统。
总体而言，门面模式的内涵在于提供一个简化、解耦、灵活、可控和可扩展的接口来访问复杂子系统。

3.使用示例

#include <iostream>// Subsystem 1
class Engine {
public:void Start(){std::cout << "Engine started" << std::endl;}void Stop(){std::cout << "Engine stopped" << std::endl;}
};// Subsystem 2
class Lights {
public:void TurnOn() { std::cout << "Lights on" << std::endl; }void TurnOff(){std::cout << "Lights off" << std::endl;}
};// Facade
class Car {
private:Engine engine;Lights lights;public:void StartCar(){engine.Start();lights.TurnOn();std::cout << "Car is ready to drive" << std::endl;}void StopCar(){lights.TurnOff();engine.Stop();std::cout << "Car has stopped" << std::endl;}
};int main()
{// Using the Facade to start and stop the carCar car;car.StartCar();// Simulate some drivingcar.StopCar();return 0;
}

4.注意事项

使用门面模式时需要注意以下事项：

过度封装：避免过度封装子系统，以至于隐藏了重要的功能或使客户端难以访问所需的特性。
性能开销：门面模式在客户端和子系统之间添加了一层间接，这可能会引入额外的性能开销。在对性能要求较高的场景中，需要考虑这一点。
灵活性受限：门面模式可能会隐藏子系统的一些功能，从而限制了客户端的灵活性。如果需要对子系统进行精细的控制，则可能不适合使用门面模式。
复杂性：当需要处理多个子系统或复杂的交互时，门面模式可能会增加复杂性。在这种情况下，可能需要考虑其他设计模式，例如中介者模式或观察者模式。
测试困难：门面模式可能会使测试变得困难，因为客户端代码依赖于门面类而不是直接与子系统交互。需要仔细考虑测试策略以确保子系统功能的正确性。

此外，还需要注意以下几点：

门面模式不适合所有场景：门面模式最适合于子系统复杂且与客户端交互频繁的情况。
门面类需要精心设计：门面类的接口应简洁且易于使用，同时还应提供对子系统功能的足够访问。
避免创建上帝对象：门面类不应成为一个庞大的上帝对象，负责处理所有与子系统的交互。它应该只提供一个简化的接口，而子系统应该负责实现实际功能。
总体而言，门面模式是一种有用的设计模式，但重要的是要了解其注意事项并在适当的情况下使用它。

5.最佳实践

发挥门面模式长处的技巧：

仔细选择要封装的子系统：门面模式最适合于封装复杂、相互依赖的子系统。选择与客户端交互频繁且具有复杂接口的子系统。
提供一个简洁易用的接口：门面类的接口应该清晰简洁，易于客户端使用。避免暴露子系统的内部细节，只提供与客户端相关的高级操作。
保持灵活性：门面模式应该允许客户端在不修改客户端代码的情况下扩展或修改子系统。通过使用抽象类或接口来定义门面接口，可以实现这种灵活性。
关注核心功能：门面类应该专注于提供对子系统核心功能的访问。避免在门面类中添加不必要的逻辑或功能，因为这会增加复杂性和降低可维护性。
利用依赖反转：通过将对子系统的依赖关系反转到门面类，可以提高代码的可测试性和可维护性。客户端代码应该依赖于门面接口，而不是具体的子系统组件。
谨慎处理性能开销：门面模式在客户端和子系统之间添加了一层间接，这可能会引入额外的性能开销。在对性能要求较高的场景中，需要仔细考虑门面模式的引入。

其他发挥门面模式长处的技巧：

使用门面模式隐藏子系统的变化：当需要更改子系统的实现时，门面模式可以作为缓冲层，使客户端代码不受影响。
简化客户端与子系统的交互：门面模式可以简化客户端与子系统的交互，使其更容易使用和维护。
提高可测试性：通过将对子系统的依赖关系反转到门面类，可以提高子系统功能的测试性。
促进代码重用：门面模式可以促进代码重用，因为门面类可以被多个客户端共享。
通过遵循这些技巧，可以充分发挥门面模式的长处，为复杂子系统的访问提供一个简化、解耦、灵活和可扩展的接口。

6.总结

门面模式图例：

+-------------------------+|                         ||                         ||       Facade Pattern    ||                         |+-------------------------+/|\\                   /|\\|||||                   ||||||||||       ----->      ||||||||||         |         |||||\\|/                   \\|/+-----------------+| SubSystem 1     |+-----------------++-----------------+| SubSystem 2     |+-----------------++-----------------+| SubSystem 3     |+-----------------+