为什么回调更“紧密耦合"?比诺言? [英] Why are callbacks more "tightly coupled" than promises?
问题描述
您能为我解释以下短语吗(取自 Stack Overflow问题的答案 Deferred和Promise之间有什么区别?和Java语言中的未来? )?
Can you explain me the following phrase (taken from an answer to Stack Overflow question What are the differences between Deferred, Promise and Future in Javascript?)?
使用 jQuery 可以避免使用以前的jQuery回调的优点是什么?
What are the pros of using jQuery promises against using the previous jQuery callbacks?
与其直接将回调传递给函数，不如 可以导致紧密耦合的接口，使用诺言可以使 对同步或异步代码的单独关注.
Rather than directly passing callbacks to functions, something which can lead to tightly coupled interfaces, using promises allows one to separate concerns for code that is synchronous or asynchronous.
推荐答案
我认为Promise与回调没有更多或更少的联系，大致相同.
I don't think promises are more or less coupled than callbacks, just about the same.
但是，承诺还有其他好处:
Promises however have other benefits:
-
如果公开了一个回调，则必须记录它是被调用一次(例如在jQuery.ajax中)还是被调用一次(例如在Array.map中).承诺总是被调用一次.
If you expose a callback, you have to document whether it will be called once (like in jQuery.ajax) or more than once (like in Array.map). Promises are called always once.
无法调用回调引发和异常，因此您必须为错误情况提供另一个回调.
There's no way to call a callback throwing and exception on it, so you have to provide another callback for the error case.
只需注册一个回调，就可以注册多个回调，并且可以在事件发生后注册它们，无论如何都会被调用.
Just one callback can be registered, more than one for promises, and you can register them AFTER the event and you will get called anyway.
在类型化声明(Typescript)中，Promise使阅读签名更加容易.
In a typed declaration (Typescript), Promise make easier to read the signature.
将来，您可以利用async/yield语法.
In the future, you can take advantage of an async / yield syntax.
由于它们是标准组件，因此您可以制作可重复使用的组件，例如:
Because they are standard, you can make reusable components like this one:
disableScreen<T>(promiseGenerator: () => Promise<T>) : Promise<T>
{
//create transparent div
return promiseGenerator.then(val=>
{
//remove transparent div
return val;
}, error=>{
//remove transparent div
throw error;
});
}
disableScreen(()=>$.ajax(....));
有关此内容的更多信息: http://www.html5rocks.com/en/tutorials/es6/promises/
More on that: http://www.html5rocks.com/en/tutorials/es6/promises/
- 另一个好处是编写了N个异步调用序列，而没有N个缩进级别.
此外，尽管我仍然认为这不是重点，但现在我认为由于这些原因，它们之间的联系更加松散:
Also, while I still don't think it's the main point, now I think they are a little bit more loosely coupled for this reasons:
-
它们是标准的(或至少是尝试):使用C#或Java中使用字符串的代码比C ++中的类似代码更糟糕，因为那里的字符串实现不同，因此更可重用.有了标准的Promise，调用方和实现之间的耦合就较少，因为它们不必在带有自定义参数顺序，名称等的(一对)自定义回调上达成共识.兑现承诺无济于事.
They are standard (or at least try): code in C# or Java that uses strings are more lousy coupled than similar code in C++, because the different implementations of strings there, making it more reusable. Having an standard promise, the caller and the implementation are less coupled to each other because they don't have to agree on a (pair) of custom callbacks with custom parameters orders, names, etc... The fact that there are many different flavors on promises doesn't help thought.
它们促进了更加基于表达式的编程，更易于编写，缓存等.
They promote a more expression-based programming, easier to compose, cache, etc..:
var cache: { [key: string] : Promise<any> };
function getData(key: string): Promise<any> {
return cache[key] || (cache[key] = getFromServer(key));
}
您可以说基于表达式的编程比基于命令/回调的编程更松散地耦合在一起，或者至少它们追求相同的目标:可组合性.
you can argue that expression based programming is more loosely coupled than imperative/callback based programming, or at least they pursue the same goal: composability.
这篇关于为什么回调更“紧密耦合"?比诺言?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
