因此,Deferred实际上非常清楚.可能令人困惑的是另一个类Promise,它使事情看起来更复杂,因为现在这个模式有两个类,它可能看起来令人困惑.
我想知道
>以上是准确的吗？
>它是一个自己的设计模式,还是实际上与其他经典设计模式类似,实际上这些“多种方法”是可能的(延迟),但“仅限制它的一个子集给予类的用户” (承诺)那种设计模式？
解决方法
E专为面向对象的安全性和多个流程中代理的强大组合而设计.承诺是确保所有E目标的重要原则.对象能力范例是访问控制列表范例的替代方案.功能不是面向用户的权限,而是分解为单个对象.授予权限就像让代理访问具有功能的对象一样简单,而OCap依赖于一个环境,在该环境中可以保证只有通过与其他对象的明确和有意的交互才能获得功能.使用弱映射(以确保内存不会泄漏)和代理(创建跨膜引用总是被包裹并且可以稍后被破坏的边界)创建对象膜也可以撤销权限.
观察和通知是单独的功能.有可能让某些代理人有权观察承诺的解决,并让其他代理人有能力解决承诺.在安全系统中,通信信道是单向的是重要的.一个解析器可以将一个值传递给所有观察者,但是没有观察者或解析器能够以其他方式干扰任何其他代理的不变量.
Promise是Gamma et Al Observer模式或Publisher,Subscriber模式的变体.还有值得注意的附加限制.承诺是广播发布者.可以通知多个观察者. Promise还保证一个解决方案,无论是解决还是拒绝.与PubSub不同,承诺将通知观察者,无论它是在调度一个分辨率之前还是之后开始观察.与事件发射器不同,承诺保证不同步.事件发射器通常在DOM和Node.js中是同步的.
出于强大的组合和安全性的目的,promise保证在单独的事件中调用所有处理程序.这可以防止函数以多种方式干扰共享同一调用堆栈的其他实体,例如调用在函数返回之前未必设置的状态关闭的函数,或者检查自己的堆栈以推断其他代理是做.
大多数JavaScript环境不足以满足promise设计的安全保证. Google Caja和DrSES是创建此类环境的项目.但是,Q promises旨在与原始设计兼容,以便为Q用户编写的代码可以更轻松地移植到这样的环境中.出于同样的原因,与其他JavaScript承诺库不同,Q也被设计为基于传递“内核”的消息的E promises,允许它们用于向其他进程中的对象发送消息,返回可能的结果的promise.用作代理以获取结果的进一步消息.
> http://en.wikipedia.org/wiki/Object-capability_model
> http://erights.org/elib/capability/ode/ode-capabilities.html
jQuery采用了承诺,但只是部分地欣赏了现有技术. jQuery中的promise是围绕jQuery自己的事件调度模式重新评估的,默认情况下有多个输入和输出,这打破了promise对应于函数调用结果(类似返回值或抛出异常)的类比. jQuery promises也不捕获异常,因此如果观察者应该被告知失败,就必须明确地创建“拒绝”.这使得某些代理无法从某些错误中恢复. jQuery还决定跟随Dojo和Twisted将promise和resolver合并为一个对象,旨在使界面更易于使用. jQuery promises最初没有为履行或拒绝的处理程序的返回值创建新的承诺,但后来纠正了这个错误.
