我正在编写代码,执行以下操作:
function getStuffDone(param) { | function getStuffDone(param) {
var d = Q.defer(); /* or $q.defer */ | return new Promise(function(resolve, reject) {
// or = new $.Deferred() etc. | // using a promise constructor
myPromiseFn(param+1) | myPromiseFn(param+1)
.then(function(val) { /* or .done */ | .then(function(val) {
d.resolve(val); | resolve(val);
}).catch(function(err) { /* .fail */ | }).catch(function(err) {
d.reject(err); | reject(err);
}); | });
return d.promise; /* or promise() */ | });
} | }
有人告诉我,这分别称为“延迟反模式”或“
Promise
构造函数反模式”,这段代码有什么不好之处,为什么将其称为antipattern? 最佳答案
deferred antipattern (now explicit-construction anti-pattern)创造的Esailija是一个常见的反模式人士,他们对诺言做出了新的尝试,当我第一次使用诺言时,我自己就做出了。上面代码的问题是无法利用承诺链的事实。
承诺可以与.then
链接,您可以直接返回承诺。您在getStuffDone
中的代码可以重写为:
function getStuffDone(param){
return myPromiseFn(param+1); // much nicer, right?
}
承诺都是关于使异步代码更具可读性,并且在不隐藏该事实的情况下像同步代码一样起作用。承诺表示对一次操作值的抽象,它们抽象出一种编程语言中的语句或表达式的概念。
您只能在converting an API to promises时使用延迟对象,并且不能自动执行延迟对象,或者在编写以这种方式表示的聚合函数时,才应使用。
报价Esailija:
这是最常见的反模式。当您不真正理解承诺并将其视为荣耀的事件发射器或回调实用程序时,很容易陷入这种情况。让我们来回顾一下:承诺是关于使异步代码保留同步代码的大多数丢失属性,例如平面缩进和一个异常通道。