1.外观模式
外观模式(Facade): 为一组复杂的子系统接口提供-一个更高级的统一接口， 通过这个接口使得对子系统接口的访问更容易。在JavaScript中有时也会用于对底层结构兼容性做统一封装来简化用户使用。
2.适配器模式
适配器模式(Adapter);将一个类(对象)的接口(方法或者属性)转化成另外一个接口，以满足用户需求，使类(对象)之间接口的不兼容问题通过适配器得以解决。
a.框架适配器
b.参数适配器
c.数据适配
d.服务器端数据适配
3.代理模式☆
代理模式(Proxy):由于一个对象不能直接引用另一个对象，所以需要通过代理对象在这两个对象之间起到中介的作用。
JSONP代理解决跨域
（后续研究利用ifram跨域）
4.装饰者模式
装饰者模式(Decorator):在不改变原对象的基础上，通过对其进行包装拓展(添加属性或者方法)使原有对象可以满足用户的更复杂需求。
装饰者模式可以在不了解原有功能的基础上对功能拓展模式，这是对原有功能的一种增强与拓展。当然同样对原有对象进行拓展的模式还有适配器模式，所不同的是适配器进行拓展很多时候是对对象内部结构的重组，因此了解其自身结构是必需的。而装饰者对对象的拓展是一种 良性拓展，不用了解其具体实现，只是在外部进行了一次封装拓展，这又是对原有功能完整性的一种保护。
5.桥接模式
桥接模式(Bridge): 在系统沿着多个维度变化的同时，又不增加其复杂度并已达到解耦。
桥接模式只是先抽象提取共用部分，然后将实现与抽象通过桥接方法链接在一起，来实现解耦的作用。是事件与业务逻辑之间的桥梁。
桥接模式最主要的特点即是将实现层(如元素绑定的事件)与抽象层(如修饰页面UI逻辑)解耦分离，使两部分可以独立变化。由此可以看出桥接模式主要是对结构之间的解耦。而抽象工厂模式与创建者模式主要业务在于创建。通过桥联模式实现的解耦，使实现层与抽象层分开处理，避免需求的改变造成对象内部的修改，体现了面向对象对拓展的开放及对修改的关闭原则，这是很有用的。当然由于桥联的添加，有时也造成开发成本的增加。有时性能上也会受到影响。
6.组合模式☆
组合模式(Composite):又称部分-整体模式，将对象组合成树形结构以表示“部分整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
例如出去吃饭，进入快餐店，如果点餐时对于喝的、吃的等一个一个点是很浪费时间的。如果餐厅能提供一个快餐服务，那么点餐就简单多了，我们仅提供套餐的名字即可，而且这个结果与我们一个一个点餐的结果是同等的，而快餐店虽然给我们提供套餐服务，但是他们仍专注于组成套餐的每-一个菜肴(组成部分)，而提供给我们的又仅仅是一个组合结果。每一种菜(部分)之间又是相对独立的，他们可以放心做好每一道菜(部分)，而最终他们又能组合出更复杂的套餐(整体)提供给我们。这种实现就是组合。
组合模式能够给我们提供一个清晰的组成结构。组合对象类通过继承同一个父类使其具有统一的方法，这样也方便了我们统一管理与使用，当然此时单体成员与组合体成员行为表现就比较一致了。这也就模糊了简单对象与组合对象的区别。有时这也是一种对数据的分级式处理。清晰而又方便我们对数据的管理与使用。当然组合模式有时在实现需求上给我们带来更多的选择方式，虽然对于单体对象的实现简单而又单一，但是通过对其组合将会给我们带来更多的使用形式。
7.享元模式
享元模式(Flyweight): 运用共享技术有效地支持大量的细粒度的对象，避免对象间拥有相同内容造成多余的开销。
享元模式主要还是对其数据、方法共享分离，它将数据和方法分成内部数据、内部方法和外部数据、外部方法。内部方法与内部数据指的是相似或者共有的数据和方法，所以将这一部分提取出来减少开销，以提高性能。就像城市里人们每天上班或者学生上学都要走一-定的路。他们有的人开私家车，有的坐公交，当然很容易看出坐公交在花费上要比私家车的开销少很多，主要是因为它让更多的人共有这一交通工具。
享元模式的应用目的是为了提高程序的执行效率与系统的性能。因此在大型系统开发中应用是比较广泛的，百分之一的效率提成有时可以发生质的改变。它可以避免程序中的数据重复。有时系统内存在大量对象，会造成大量内存占用，所以应用享元模式来减少内存消耗是很有必要的。不过应用时一定要找准内部状态(数据与方法)与外部状态(数据与方法)，这样才能更合理地提取分离。当然在一些小型程序中，性能与内存的消耗对程序的执行影响不大时，强行应用享元模式而引入复杂的代码逻辑，往往会收到负效应。