设计模式中的facade外观模式在JavaScript开发中的运用
作者：TAT.svenzeng
概念
外观模式(门面模式)，是一种相对简单而又无处不在的模式。外观模式提供一个高层接口，这个接口使得客户端或子系统更加方便调用。
外观模式并不是适配器模式，适配器模式是一种包装器，用来对接口进行适配以便在不兼容系统中使用它。而创建外观元素则是图个方便。它并不用于达到需要特定接口的客户系统打交道这个目的，而是用于提供一个简化的接口。
JavaScript代码示例
用一段再简单不过的代码来表示
var getName = function(){
return ''svenzeng"
}
var getSex = function(){
return 'man'
}
如果你需要分别调用getName和getSex函数. 那可以用一个更高层的接口getUserInfo来调用.
var getUserInfo = function(){
var info = a() + b();
return info;
}
也许你会问为什么一开始不把getName和getSex的代码写到一起, 比如这样
var getNameAndSex = function(){
return 'svenzeng" + "man";
}
答案是显而易见的，饭堂的炒菜师傅不会因为你预定了一份烧鸭和一份白菜就把这两样菜炒在一个锅里。他更愿意给你提供一个烧鸭饭套餐。同样在程序设计中，我们需要保证函数或者对象尽可能的处在一个合理粒度，毕竟不是每个人喜欢吃烧鸭的同时又刚好喜欢吃白菜。
外观模式还有一个好处是可以对用户隐藏真正的实现细节，用户只关心最高层的接口。比如在烧鸭饭套餐的故事中，你并不关心师傅是先做烧鸭还是先炒白菜，你也不关心那只鸭子是在哪里成长的。
最后写个我们都用过的外观模式例子
var stopEvent = function( e ){ //同时阻止事件默认行为和冒泡
e.stopPropagation();
e.preventDefault();
}
我知道外观模式的概念很容易掌握，你都不一定需要一个JavaScript代码的例子，但是总有些人更在乎代码，会觉得那样才更容易理解。更何况，没有代码示例的JavaScript文章根本就不具说服力，就应该从网上删掉。 我们从一个简单的事件监听器的例子开始。大家都知道要添加一个事件监听器并不是一件容易的事，除非只想让代码运行在少数几个浏览器上。你不得不测试很多方法以确保针对不同浏览器的代码都能正常运行。在这个代码示例中我们只是把特性检测添加到这个方法中：
function addEvent(element, type, func) {
if (window.addEventListener) {
element.addEventListener(type, func, false);
}
else if (window.attachEvent) {
element.attachEvent('on'+type, func);
}
else {
element['on'+type] = func;
}
}
简单吧！我真希望我可以不用写那些不必要的代码，让它们越简单越好，但是如果真是这样就没什么意思了，你也不会想读下去了，对吧？所以我不这么认为，我想我要给你看点更复杂的东西。我只是想说，你的代码原本看起来会有些像下面这样：
var foo = document.getElementById('foo');
foo.style.color = 'red';
foo.style.width = '150px';
var bar = document.getElementById('bar');
bar.style.color = 'red';
bar.style.width = '150px';
var baz = document.getElementById('baz');
baz.style.color = 'red';
baz.style.width = '150px';
太蹩脚了！你对每个元素做了一模一样的事！我认为我们可以让它变得更简单点：
function setStyle(elements, property, value) {
for (var i=0, length = elements.length; i < length; i++) {
document.getElementById(elements[i]).style[property] = value;
}
}
// 现在你可以这么写：
setStyle(['foo', 'bar', 'baz'], 'color', 'red');
setStyle(['foo', 'bar', 'baz'], 'width', '150px');
是不是觉得咱们NB坏了？你快算了吧！咱们可是JavaScript程序员呀！能不能用点脑子，来点真格的。也许我们可以只调用一次就能设置所有的样式。看下这个：
function setStyles(elements, styles) {
for (var i=0, length = elements.length; i < length; i++) {
var element = document.getElementById(elements[i]);
for (var property in styles) {
element.style[property] = styles[property];
}
}
}
//现在你只要这样写：
setStyles(['foo', 'bar', 'baz'], {
color: 'red',
width: '150px'
});
如果我们有很多元素想设置相同的样式，那这段代码真是为我们节省了不少时间。
外观模式之利：
使用外观模式的目的就是要让程序员过的更轻松一些，编写一次组合代码，然后就可以反复使用它，这有助于节省时间和精力。给一些复杂的问题提供一个简化接口。
外观方法方便了开发人员，斌共提供过了比较高层的功能，降低对外部代码的依赖程度，为应用系统的开发增加了一些额外的灵活性。通过使用外观模式，可以避免与下层子系统紧密耦合。这样就可以对这个系统进行修改而不会影响到客户代码。
外观模式之弊：
有时候外观元素也会带来一些不必要的额外负担。在实施一些套路之前应该认真掂量一下其实用性。有时相比一个庞杂的外观函数，其组成函数在力度方面更有吸引力。这是因为外观函数可能常常会执行一些你并不需要的任务。
对于简单的个人网站或少量营销网页来说，仅为工具提示和弹出式窗口这样一点增强行为就导入这个Javascript库可能并不明智。此时考虑只使用少许简单的外观元素而不是一个满是这类东西的库。
外观函数为执行各种复杂任务提供了一个简单的接口，它们使代码更容易维护和理解。它们还能弱化子系统和客户代码的耦合。把经常相伴出现的常用函数组合在一起。这个模式在DOM脚本编程这种需要面对葛洪不一致的浏览器接口的环境中很常用。