3.当需要构建一个层次结构的子系统时，使用外观模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，我们就可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
总结
外观模式简单易用，让客户能更简单的去使用子系统；在拜读别人的文章时，有以下总结非常好，我也借鉴一下：
1.在设计初期，应该有意识的将不同层分离，比如常用的三层架构，就是考虑在数据访问层，与业务逻辑层表示层之间，建立Facade，使复杂的子系统提供一个简单的接口，降低耦合性；
2.在开发阶段，子系统往往因为不断的重构而变的越来越复杂，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖；
3.在维护阶段，可能这个系统已经非常难以维护和扩展了，此时你可以为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。
通常来讲，对于子系统的访问，我们提供一个Facade层，而这个Facade入口，只需要一个；也就是说在使用Facade时，我们可以使用单例模式来实现Facade模式。对于外观模式到此就总结完成了，肯定有一些地方遗漏了，请大家指正。我坚信，分享使我们更加进步。
