设计模式：外观模式（Facade模式）
Facade（外观）模式为子系统中的各类（或结构与方法）提供一个简明一致的界面，隐藏子系统的复杂性，使子系统更加容易使用
当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度
外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。
降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
外观（Facade）模式的主要缺点如下。
不能很好地限制客户使用子系统类，很容易带来未知风险。
增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
1. 模式的结构
外观（Facade）模式包含以下主要角色。
外观（Facade）角色：为多个子系统对外提供一个共同的接口。
子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
客户（Client）角色：通过一个外观角色访问各个子系统的功能
实现代码：（纯手打，如果有错误应该问题不大）
首先定义外观角色：
class Facade{
private SubSystem1 obj1 = new SubSystem1();//对子系统1的引用
private SubSystem2 obj2 = new SubSystem2();//对子系统2的引用
private SubSystem3 obj3 = new SubSystem3();//对子系统3的引用
/**
/*提供访问子系统功能的接口
*/
public useSys1(){
obj1.used();
}
public useallSys(){
obj1.used();
obj2.used();
obj3.used();
}
}
//定义子系统角色
class System1{
used(){
console.log("子系统1的used功能"被调用);
}
}
class System2{
used(){
console.log("子系统2的used功能"被调用);
}
}
class System3{
used(){
console.log("子系统3的used功能"被调用);
}
}
//提供客户角色通过外观模式访问各子系统的功能
class Client1{
private f:Facade = null;
constructor(){
f = new Facade();
}
//调用方法
usesystem1(){
f.useSys1();
}
}
facade可以通过继承方式扩展，以上代码为界面纯手打，可能有错误，但逻辑应该是对的
