JavaScript设计模式

设计模式:结构型

结构型设计模式则有助于把多个对象整合为一个更大型的、更有组织性的代码库。当某一部分发生改变，不必完全重写。帮助我们与其他代码结构进行对接。

1.适配器模式
当需要关联两个或更多的代码组件时便可应用此模式，否则这些代码无法兼容到一起工作。
2.组合模式
组合模式为一个或多个对象创建了一个接口，使终端用户不需要知道他们所处理对象的个数。

若不希望那些正与你的方法进行交互的开发者操心需要传入多少个对象作为方法参数，使用组合模式最为合适，这样可以简化方法的调用。
3.装饰模式
装饰模式用于为某个“类”创建的对象扩展和定制额外的方法和属性，避免了因创建大量的子类而变得难以维护。其实现方法是，通过有效地将对象包装在另一个对象中，另一对象实现了相同的公共方法，根据我们所要增加的行为对相关方法进行重写。

当需要快速且简便地为从一个“类”所创建的对象实例增加行为，而又不借助与创建一系列的从继承与该“类”的子类来实现时，使用装饰模式最为合适。
4.外观模式
通过编写一个单独的函数，来简化对一个或多个更大型的、可能更为复杂的函数的访问。

当需要通过一个单独的函数或方法来访问一系列的函数或方法调用，以简化代码库的其余内容，使得代码更易于跟踪管理并因而在日后更容易维护和伸缩，使用外观模式最为合适。

5.享元模式
享元模式是一种关于优化的模式。对于那些需要创建大量的相似对象却因此而消耗大量内存的代码来说，应用享元模式是很有帮助的。

当面对大量的对象时，若在这些对象里面有着一些相似的共有属性“名称-值”对，这些属性“名称-值”对可以分离成为更小的对象，可通过对这些小对象的引用来实现数据分享，使代码的内存占用更少，使代码运行更高效，则此时应用享元模式最为合适。

6.掺和模式
掺和模式通过快速并简易地从一个对象中把一组方法和属性直接应用至其他对象，或应用至“类”的prototype，使得类的所有对象实例都能够访问这些属性和方法，从而避免了产生大量的子类和继承链的需要。

当希望能够快速地直接从一个对象把一组属性和方法应用至另一对象，做应用至另一个“类”以供它的所有的对象实例使用，而不需要借助复杂的子类和继承来实现时，使用掺和模式最为适合。

7.当希望把大型的代码库分解为更小的、更易管理的、自我包含的多个组成部分，而每部分都有明确的依赖项，每部分有清晰定义的使用目的时，使用模块模式最为合适。

8.代理模式
代理模式是通过定义一个代理对象或方法来替换或增强一个已经存在的对象和方法，以提升其性能或增加额外的功能，但又不影响已经使用了该对象或方法的其余部分代码。

当需要重写某对象或“类”上的特定方法的行为，或者重写方法以提升某个已有“类”的性能，使得直至该“类”的方法被调用时才真正对该“类”进行实例化时，使用代理模式最为合适。

 设计模式：行为型

行为型设计模式侧重于辅助实现代码库中的多个对象之间的通信，使我们更易从整体角度理解代码是如何在一起运作的，而不是着重与单独的对象创建与结构。

1.职责链模式

当基于一个相同的类的若干个类可以相应地处理某项请求或调用时，可以使用职责链模式。该项请求首先发送至一个对象，如果一个对象不能亲自处理到达的请求，就会有职责链中的下一继任对象来处理。当多个对象在一起能组合成某种类型的层级关系，但我们又不希望向代码的其他部分暴露其中的实习过程，则此时使用职责链模式最为合适。

2.命令模式

通过确保所有的调用都经过某个对象上的一个单独、公共的方法（通常命名为run（）或execute（））发出，命令模式可以为发起调用的代码与某个对象的特定方法之间提供一个抽象层。使用此模式可以更改底层代码和API，但又不影响那些发起调用的代码。

当需要从代码的其余部分抽象出特定方法的名称时，使用命令模式最为合适。通过方法的名称来引用方法，可以在任意时刻更改底层的代码而又不影响代码的其余部分。

3.迭代器模式

顾名思义，迭代器模式可以使应用程序中的代码对一个数据集合进行迭代和循环访问，但又不清楚该数据在内部是如何保存和构建的。通常，迭代器会提供一组标准方法，用于移动至该集合中的下一个数据项，还用于检查当前数据项是否位于集合中的第一项或最后一项。

当需要为代码的其余部分提供一种标准的方法来对复杂数据结构进行迭代循环访问，但又不暴露该数据是如何保存或表示时，使用迭代器模式最为合适。

4.观察者模式

观察者模式所使用的场合是由多个独立代码模块所组成的较大型代码库，各个模块之间需要相互依赖或相互通信。对于这样的一个代码库，从一个模块对另一个模块的硬编码引用就被称为紧耦合，它需要明确系统中的其他每个模块才能使整体代码正确的运行在一起。然而，理想情况是，在大型代码库中的模块应该是松耦合。引用不能是显式地指向其他模块。相反，要在整个代码库进行去系统性的事件发布和监听，就好比一个自定义版本的标准DOM事件处理。

利用观察者模式移除代码中各模块之间硬编码引用，以支持实现一个易于维护的自定义的、全系统的事件列表。随着代码库的增长和模块数量的增加，要考虑使用该模式来对代码进行简化，以及实现各模块之间的解耦。请注意，如何某个模块出现了错误，某个事件没有理所当然地发出，则该错误的根源可能不会立即明显地出现，需要额外的调试。推荐在开发期间向观察者对象里增加调试日志记录功能，以便更容易地追踪代码中的各种事件。

当希望实现各模块之间的松耦合以减少意大利面条式代码时，则使用观察者模式最为合适。