设计模式笔记(6 FACADE)

FACADE（外观）
适用性：
1.需要为一个复杂子系统提供一个简单接口时，为子系统提供一个简单的外观。
2.客户程序与抽象类的实现之间存在很大的依赖性
3.当需要构建一个层次结构的子系统时，使用FACADE来定义子系统中每层的入口点。

思考：
    关于第一点，好处是明显的，它降低了客户的学习成本。但是，一般而言，如果这个子系统是一个定制的子系统，可能直接提供一个简单接口更省事。如果这个子系统来是已经实现了的，或者存在必须访问子系统内部组件的可能，这个时候使用FACADE可能更恰当。另外，提供一个FACADE，供二次开发，也是非常有价值的。FACADE的特别之处在于，外观并不打算隐藏内部的子系统，只是希望可以降低客户使用该子系统的学习成本和使用成本。实际上，有点为常见应用环境定制一个接口包的意思。从这一点出发，是否可以得出一个推论：我们可以为一个子系统提供多个独立的FACADE，从而简化多个典型的常见情形的使用成本？
    关于第二点，从依赖倒置的原则来说，实现应该围绕上层的需要来设计接口。如果是这样，那也就没有FACADE存在的必要了。我想，出现需要FACADE的情况是什么呢？一个是，这个子系统相当独立，并且，我们在这样一个子系统上已经有了充分的认识，那么按照这个子系统本身的逻辑来实现是最自然的。另一个情况是，这个子系统过于复杂，在实现上，不得不充分尊重如何实现该子系统。
    FACADE模式的目的是降低使用成本，也具备一定的划分子系统的功能。但FACADE并不打算封装其所在的子系统。那样的化，FACADE可能变得过于笨拙和复杂，反而为用户带来负担。