1、组合模式：
1.1、表单验证
topForm对象将在其所有子对象上递归调用save方法，实际上的save操作只会发生在底层的叶对象上。组合对象只起到一个传递调用的作用。example
1.1.1、向FormItem添加操作：example
1.2、向层次体系中添加类：
我们可以把域组织在域集中，每一个域集都是一个实现了FormItem接口的组合对象，在域集上调用restore将导致在其所有子对象上调用restore。example
1.3、示例：图片库
创建一个图片库，有选择地隐藏或显示图片库的特定部分。这可能是单独的图片，也可能是图片库。example
1.4、组合模式之利：
简单的操作也能产生复杂的结果，只需对最顶层的对象执行操作，让每一个子对象自己传递这个操作即可。这对于那些再三执行的操作尤其有用。
在组合模式中，各个对象之间的耦合非常松散。只要它们实现了同样的接口那么改变它们的位置或互换它们只是举手之劳。着促进了代码的重用，也有利于代码重构。
每当对顶层组合对象执行一个操作时，实际上是在对整个结构进行深度优先的搜索以查找节点，而创建组合对象的程序员对这些细节一无所知。在这个层次体系中添加、删除和查找节点都非常容易。
1.5、组合模式之弊：
组合对象的易用性可能掩盖了它所支持的每一种操作的代价。由于组合对象调用的任何操作都会被传递到它的所有子对象如果这个层次体系很大的话，系统的性能将会受到影响。组合模式的正常运作需要用到某种形式的接口。
组合对象和节点类被用作HTML元素的包装工具时，组合对象必须遵守HTML的使用规则。例如，表格就很难转化为一个组合对象。
接口检查越严格，组合对象类也就越可靠。
2、外观模式：
外观模式并不是适配器模式，适配器模式是一种包装器，用来对接口进行适配以便在不兼容系统中使用它。而创建外观元素则是图个方便。它并不用于达到需要特定接口的客户系统打交道这个目的，而是用于提供一个简化的接口。
2.1、实现外观模式的一般步骤：
找准自己的应用程序中感觉适合使用门面方法的地方后，就可以着手加入便利方法了。这些函数的名称应经仔细考虑，与它们的用途要相称。对于那种由几个函数组合而成的函数，一个简单的办法就是把相关函数的名称串联成一个函数名，并采用camel大写规范，或者也可以使用thisFunctionAndThatFunction这种形式。
处理浏览器API的不一致性属于另一种情况，此时要做的就是把分支代码放在新创建的门面函数中，辅以对象检查或者浏览器嗅探等技术。
2.2、外观模式的适用场合：
判断是否应该应用外观模式的关键在于辨认那些反复成组出线的代码。如果函数b出现在函数a之后这种情况经常出现，那么也许你应该考虑添加一个把这两个函数组合起来的外观函数。
另一种情况是应对Javascript内置函数在不同浏览器中不同表现。最好的解决办法就是把这些差异抽取到外观方法中，它们可以提供一个更一致的接口。
2.3、外观模式之利：
使用外观模式的目的就是要让程序员过的更轻松一些，编写一次组合代码，然后就可以反复使用它，这有助于节省时间和精力。给一些复杂的问题提供一个简化接口。
外观方法方便了开发人员，斌共提供过了比较高层的功能，降低对外部代码的依赖程度，为应用系统的开发增加了一些额外的灵活性。通过使用外观模式，可以避免与下层子系统紧密耦合。这样就可以对这个系统进行修改而不会影响到客户代码。
2.4、外观模式之弊：
有时候外观元素也会带来一些不必要的额外负担。在实施一些套路之前应该认真掂量一下其实用性。有时相比一个庞杂的外观函数，其组成函数在力度方面更有吸引力。这是因为外观函数可能常常会执行一些你并不需要的任务。
对于简单的个人网站或少量营销网页来说，仅为工具提示和弹出式窗口这样一点增强行为就导入这个Javascript库可能并不明智。此时考虑只使用少许简单的外观元素而不是一个满是这类东西的库。
外观函数为执行各种复杂任务提供了一个简单的接口，它们使代码更容易维护和理解。它们还能弱化子系统和客户代码的耦合。把经常相伴出现的常用函数组合在一起。这个模式在DOM脚本编程这种需要面对葛洪不一致的浏览器接口的环境中很常用。
