Javaｓｃｒｉｐｔ设计模式的外观模式介绍
外观模式描述描述：外观模式是由复杂的子系统和子系统提供的高级接口。客户机更容易访问底层程序或系统接口。
外观模式是我们经常遇到的模式。我们经常涉及到的功能可能涉及多个子接口或子系统，和我们的一个功能，可能只需要一个或一个以上的多个子接口时序的包。如果业务功能直接对应的子接口或子系统，它可以要求开发商有一个良好的内在需要；你需要知道的企业的流程是如何走，什么订单等等。这需要开发人员了解企业，使客户程序相当复杂；
如果有一个层，在这里，或一类，专门提供好的包装方法，我们使用，客户端功能仅需要与中间阶级的相互作用，对人员组织包的中产阶级，必须了解相应的业务方法的发展相关，那么程序将变得非常简单，程序员只需要知道他所对应的功能的方法，不需要知道内部的逻辑。
这个中产阶级是我们所说的外貌阶级，这就是外观模式的概念。
现场实例：
例如，1 >。开关例子，这个开关，一盏灯可以控制到房子的门，几盏灯的大厅，并控制电源的电视，冰箱，你把小按钮上，这将有一个直接的电，甚至热传输，你不知道这一点。总开关按钮是要打电话，或是如何根据有关电器，直接对美国施压。
这些灯、电视机等是我们想要使用的接口，小型系统。总开关是我们的外观类别。我们可以直接面对它。
2 >。比一个公司，有几个职能部门，有一天老板必须执行所有的工作，他在一个部门，问员工说一定要做的事情，如果你问对人直接听命于老板，如果不是这个人负责，他将与老板说，哦，这是谁负责的老板，就跑去问人，很多麻烦。
如果每个职能部门都有一个负责人，老板可以直接去了解情况。老板不必在意责任人怎么知道这件事。他只是想知道1,2,3的现状和进展。
示例源代码
现在，源代码在第二个场景中实现。
1。功能类别：
1部门（工商部门）：
复制代码代码如下所示：
功能businessdept（）{
this.manager = '陈'； / /负责人
}
businessdept.prototype = { {
monthsales：函数（）{
console.log（this.manager +说：这个月的销售是xxx）；
}，
NextPlan：函数（）{
console.log（this.manager +说：下一步的计划是这样的，XXXX）；
}
}
2部（研发部）：
复制代码代码如下所示：
功能rddept（）{
this.manager = '经理黄；
}
rddept.prototype = { {
进度：函数（）{
console.log（this.manager +表示：目前项目的状况和进展是xxx）；
}，
DeptPlan：函数（）{
console.log（this.manager +说：下一部的计划是一个XXX）；
}
}
以上是每个部门的负责人应该回答老板的问题。
然后设置外观类来组织老板想问的问题。
复制代码代码如下所示：
函数外观（）{
this.business =新businessdept（）；
this.rddept =新rddept（）；
}
facade.prototype = { {
deptsituation：函数（）{
（这个业务。monthsales）； / /销售经理说；
this.rddept.progress（）；
}，
DeptPlan：函数（）{
（这个业务。nextplan）； / /下一步的计划报告；
This.rddept.deptPlan（）；
}
}
然后老板把两个经理叫到他们面前，开始问：
复制代码代码如下所示：
新立面（）；
console.log（老板问：现在介绍自己的部门）；
facade.deptsituation（）；
console.log（老板问：下一步的计划是什么
facade.deptplan（）；
其他说明
外观模型的使用，可以使接口或类之间的解耦，班上没有依靠，没有必要在使用含有B或B必须包含，它违背了使用中间层封闭改造的原则，包装的外观，可以使界面变得简单，使用子或子接口对象的系统调用更多的自由，可以组织。
外观模式经常发生。在我们的程序设计中，外观模式常常被用于架构系统的模式定义。我们的系统应该使用第三方接口服务，并且经常添加层外观层来组织可用的业务接口。