在北京待了两天感受到了学校深深的恶意。开着空调看书才舒服了一点又被宿管断了电。从头看设计模式。

Constructor（构造器）模式

  • 对象创建，通过对象字面量或者 Object.create
  • 基本构造器，所有属性和方法丢在构造器里。不适合继承，因为有些方法需要在不同实例间共享（应该是不需要在执行构造器的时候再创建一遍的意思吧）
  • 带原型的构造器

Module（模块）模式

  • 对象字面量表示法
  • 引入混入，将全局变量作为参数传递给模块的匿名函数；引出，声明全局变量而不需要实现（理解不了。。）
  • 缺点在于无法为私有成员创建自动化单元测试
  • Revealing Module（揭示模块）模式，返回匿名对象，其属性引用希望对外的私有函数或变量。引用私有变量的公共成员和引用公共成员的私有函数遵循无补丁规则。
  • Singleton（单例）模式，限制了类只能实例化一次。如果实例存在，则返回该对象的引用。可延时构建，区别于静态实例（对象）

  • Observer（观察者）模式
    一个或多个观察者对目标的状态感兴趣，它们通过将自己依附在目标对象上以便注册所感兴趣的内容。目标状态发生改变并且观察者可能对这些改变感兴趣，就会发送一个通知信息，调用每个观察者的更新方法。当观察者不再对目标状态感兴趣时，它们可以简单地将自己从中分离

    • Observer 模式，要求收到观察者直接订阅内容改变的事件。通过直接在对象上继承订阅和发布方法实现
    • Publish/Subscribe 模式，使用主题/事件通道促进松散解藕，缺点存在于耦合松散，观察者无法发现订阅者的报错

    • Mediator（中介者）模式，即广播，通过限制对象严格通过Mediator 进行通信实现。与发布/订阅模式的实现基本相同，但消除了订阅和发布者间的关系，维护中心联络点

      观察者模式和中介者模式的区别在于，前者存在发布者和订阅者之间的关系，而后者维护中心联络点。体现在于前者实现了 unsubscribe 方法，而后者没有

  • Facade（外观）模式，为模块或系统定义了一个简单接口，隐藏底层复杂性。属于结构型模式，常与其他模式集成。抽象带来性能成本

  • Prototype（原型）模式
    • 通过Object.create 实现继承
    • 通过直接将原型指向对象实现继承
    • 原型带来性能提升，对象里面定义函数，通过引用创建，而非单份拷贝
  • Command（命令）模式，将方法调用、请求或操作封装到单一对象，通过传递参数调用，实现该操作的对象解藕
  • Factory（工厂）模式，隐式构造函数
  • Mixin 模式，可被子类或一组子类继承功能，目的是代码复用
    • 子类化，从超类对象继承相关的属性。通过 apply 或 call 调用超类的构造函数继承属性，不包含原型
    • Mixin（混入），作为一种扩展收集功能的方式，允许对象通过较低的复杂性借用或继承功能。用于函数复用和共享功能。有可能导致原型污染和函数起源方面的不确定性。
  • Decorator（装饰者）模式，将行为动态添加至系统现有类。不改变原有对象的构造函数属性和方法
  • Flyweight（享元）模式，用于优化重复、缓慢及数据共享效率较低的数据。可用于数据层和 DOM 层（事件捕捉与事件冒泡）

Javascript MV* 模式

  • MVC 中，Model 管理应用程序的数据，View 是 Model 的可视化表示，Controller 是 Model 和 View 之间的中介，是 View 策略模式的简易化。在策略模式方面，View 在其判断力下将委托给 Controller 进行操作。其依赖于 Observer 模式实现一些核心通信（四人组认为 MVC 是一系列用户构建用户界面的类而非设计模式，书中也多次提到 MVC 中 Model 会通知 View 更新，与之前了解的 MVC 有一些差别，不解。。。也许是 Javascript 的 MVC 框架在解释 MVC 方面与经典 MVC 的不同）
  • MVP 模型-视图-表示器，P 将 M 有效绑定到 V。V 通过接口定义，提高应用程序的可测试性，并在 View 和 Model 之间提供更清晰的分离，缺乏数据绑定支持，需要单独关注任务
  • MVVM 中，ViewModel 可以被解释为在 UI 上执行的数据和操作的表示，是一个用于保存用户正在使用且尚未保存的数据的层。View 和 ViewModel 之间通过数据通信和事件进行通信，View 处理自己的用户界面事件，必要时将他们映射到 ViewModel。Model 和 ViewModel 通过双向数据绑定进行同步和更新。ViewModel 可以为了数据绑定而暴露 Model 或 Model 属性，也可以包含接口，用于获取和操作在 View 中暴露的属性
  • MVC、MVP 与 MVVM
    • MVC 中，View 位于架构之上，与 Controller 相邻。Model 位于 Controller 之下，View 委托 Controller，Controller 更新 Model，View 也可以直接访问 Model
    • MVP 中，Controller 的作用被 Presenter 所替代，Presenter 与 View 位于同一位置，监听 View 和 Model 的时间，并调解他们的行动。与 MVVM 不同的是 MVP 没有将 View 绑定至 ViewModel，转而依赖每个 View 来实现用于 Presenter 与 View 之间进行交互的接口
    • MVVM 中 ViewModel 可以看作 Model 特定于 View 的子集。与 MVP 的Presenter 不同，MVVM 中 Model 引用 View 不需要 ViewModel，View 可以绑定 ViewModel 上面的属性，而属性会暴露 Model 给 View。

模块化的 Javascript 设计模式

  • AMD 采用浏览器优先的开发方法，选择异步行为和简化的向后兼容性，但是它没有任何文件I/O的概念。
  • CommonJS 采用服务器优先方法，假定同步行为，没有全局概念，迎合服务器语言。支持非包装模块，更接近下一代 ES Harmony 规范。仅将对象作为模块给予支持
  • UMD 是用于插件的 AMD 和 CommonJS 兼容模块，通过检验是否存在相应的全局变量将模块按照 AMD 或者 CommonJS 规范导出
  • ES Harmony 增加了类和模块的特性，js 更像 java

jQuery 中的设计模式

  • Composite（组合）模式，描述了一组对象，可以使用与处理对象的单个实例同样的方式来进行处理。这是的我们能够以统一的方式来处理单个对象和组合
  • Adapt（适配器）模式，将对象或类的接口转变为与特定的系统兼容的接口
  • Facade（外观）模式
  • Observer（观察者）模式
  • Iteraor（迭代器）模式
  • 延迟初始化
  • Proxy（代理）模式，为其他对象提供一种代理以控制这个对象的访问，解决直接访问某些对象是出现的问题。常用于替换上下文
  • Builder（生成器）模式

jQuery 插件设计模式

  • 命名空间基础
    • 立即调用的函数表达式（IIFE），把命名空间为参数传入匿名函数
    • 命名空间注入，通过 apply 调用修改上下文实现命名空间的填充
小记：本书带来最大的感受是对于之前使用过或者接触过的模式有了定义；JS MV* 模式，与之前自己的认识有一定差异，但确实能更加清晰的了解到是出于什么原因而选用何种模式；构造函数和原型当作对象处理也没有问题的样子；模块化的几种规范的明确定义，AMD、CommonJS、以及正在使用的所谓 CMD；jQuery 中很多优秀的地方，在之后的 jQuery 源码一书中继续学习。