外观模式

这一篇博客记录一下外观模式。

---

我们依然先用Head First中的例子，看看外观模式使用的场景。

假设用户在自家组了一个家庭影院，
家庭影院包括一大堆的组件，
例如屏幕、灯光、调音器、播放器等等。

现在为了操作这个家庭影院，
用户需要直接与Screen、TheaterLights、
Tunner、CdPlayer等类打交道。

随着子类数量的增加和变化，客户端代码将逐渐变得复杂，
同时需要不断修改。

外观模式的存在就是为了解决这种问题的。

如上图所示，在各种组件之上增加了一个HomeTheaterFacade类。
此时，Client仅与HomeTheaterFacde打交道，
由HomeTheaterFacade来管理底层子系统的细节。

于是，增加或修改组件时，客户端代码就不需要修改了。

从上面的例子可以看出，外观模式实际上就是简化接口的调用，
同时将客户从组件的子系统中解耦。

---

对外观的使用场景有了基本的了解后，
我们来看看外观模式的定义及结构图。

外观模式提供了一个统一的接口，用来访问子系统中的一群接口。
外观定义了一个高层接口，让子系统更容易使用。

从上述定义可以看出，外观的意图就是提供一个简单的接口，
好让一个子系统更易于使用。

当然，如果需要，用户也可以直接和子系统中的类打交道。

---

个人感觉外观模式，就是在重构代码的过程中，
逐渐生长出来的设计方式。

例如，在代码级别，当多个语句被重复使用时，
我们会自然将它们抽取成一个函数，简化使用过程。

同样，到了类这个级别，当一组关联的功能需要多个类来支持时，
我们也会将这一组功能放到一个单独类里，例如各种Util类。
然后在使用时，只与新创建的类交互。

再到操作系统这个级别，
整个操作系统就是为上层开发人员和应用提供统一的接口，
简化对底层硬件的操作而已。

因此，个人感觉外观模式，可能是最不需要刻意使用的模式。

不过，我们需要理解的是，外观模式的最终目的只是方便了客户端用户。
与子系统交互的复杂性依然存在，只是被放到了Facade而已。