deferred/promise是否会违反Demeter法？

Question

我在洗澡时想到了什么.

递延/许模式是降低回调地狱,允许开发者链通话功能,如提到这里:

Parse.User.logIn("user", "pass").then(function(user) {
  return query.find();
}).then(function(results) {
  return results[0].save({ key: value });
}).then(function(result) {
  // the object was saved.
});

从我的头脑中 - 纠正我,如果我错了 - 但似乎使用延期/承诺是打破德米特定律的简单方法？

得墨忒耳法则规定:

对象的方法只能调用以下方法:

• 对象本身.
• 方法的一个论点.
• 在方法中创建的任何对象.
• 对象的任何直接属性/字段.

每个单位应该对其他单位的知识有限:只有与当前单位"密切"相关的单位.或者:每个单位只应与其朋友交谈; 不要和陌生人说话.

对此有何评论？

2013年12月1日更新:

我的问题的摘要版本.Promise框架旨在简化异步编码并避免" 回调地狱 ".Promise最有用的功能之一是你可以使用链式调用事件.then(),如上例所示.

鉴于所有的代码/函数现在都在使用Promise(就像Benjamin Gruenbaum(下面的作者)目前正在做的那样),它不会打开它以使链调用函数变得非常简单.then().then().then().

编写链接调用函数的代码(.then().then().then())必须是如何打破Demeter法则的教科书示例.

因此,我的问题; Promise框架是否促进/开放/更容易滥用/违反Demeter法？

Answer 1

我认为你误解了Demeter定律的含义及其对JavaScript和承诺等框架这两种语言的适用性.

在Demeter法律设想的意义上,承诺不是"单位",它对应于诸如银行应用程序中的账户或客户之类的"类".它们是异步控制流的更高级元构造.很难看出这样的元构造如何能够存在,或者是有用的,而不能"与"设计用来控制的任意外部实体(非朋友)"交谈".

德米特定律似乎高度关注经典的OO系统,其中一切都是一类或一种方法.如上所述,它似乎不允许任何传入函数的调用,因此大多数(如果不是全部)函数编程都是如此.

另一种看待这种情况的方式是,如果你认为承诺违反了这个法律,那么回调当然也会这样做.毕竟,这两者基本上是同构的 - 差异基本上是句法的.因此,如果您注意不违反Demeter定律,那么您也无法使用回调 - 那么您将如何编写最基本的异步程序？

Answer 2

简短的回答是肯定的.

我认为这已经变得比必要的复杂化了,因为人们把这个问题弄糊涂了,虽然有趣但与德米特定律没有直接关系.就像我们正在谈论JavaScript一样.或者我们正在处理回调的事实.这些是不适用的细节.

让我们退一步重新讨论.软件工程的首要目标是尽可能地限制耦合.换句话说,当我更改代码时,我想确保这不会迫使我在周末工作以更改大量其他代码.德米特定律的存在是为了防止一种耦合 - 特征嫉妒.它通过为方法f用于完成其工作的内容提供正式限制来实现.

OP @corgrath很好地枚举了这些限制.表征违反德米特定律的一种简单方法是:"你不能在任何允许的4个物体上调用任何方法."

现在最后来看@corgrath提供的示例代码:

Parse.User.logIn("user", "pass").then(function(user) {
  return query.find();
}).then(function(results) {
  return results[0].save({ key: value });
}).then(function(result) {
  // the object was saved.
});

让我们称Parse一个数据结构而不是一个对象(参见鲍勃叔叔的精彩书籍清洁代码的第6章,这是我第一次接触到得墨忒耳法,更多关于这个区别).然后我们很好Parse.User.

但User显然是方法和行为的对象.其中一种方法是logIn.这会返回一个Promise.一旦我们对此物体发出任何声明,我们就违反了得墨忒耳法则.

而已.

顺便说一下,我还会很快提到JavaScript 函数中的对象.因此,Demeter法也适用于传递给每个then调用的回调函数.但是在每一个函数的方法中都没有调用,因此then调用不违反得墨忒耳定律.

现在有趣的是这种明显违反德米特定律是否重要.软件工程是一门艺术.我们有各种各样的法律,原则和实践,但是对它们的宗教信仰与对它们的无知一样适得其反.尝试100%代码覆盖是愚蠢的; 单元测试getter和setter是愚蠢的; 争取100%的阶级凝聚力是愚蠢的; 创造100%包装稳定性是愚蠢的; 等等

在这种情况下,我会说违反德米特定律并不重要.Promises不以任何方式暴露内部构件; 他们公开了一个抽象来执行另一个动作(在这种情况下,注册一个回调,但这与讨论无关).换句话说,我是否必须担心周末工作所有这些then电话？可能性是realllly低.我的意思是他们可能会将方法重命名为andThen或whenYoureReadyDoThis,但我对此表示怀疑.

这是一个大问题,因为我喜欢我的周末.我不想处理不必要的事情.我想做一些有趣的事情,比如在Stack Overflow上发表论文答案.

总而言之,有两个问题:

• Promise代码是否符合得墨忒耳法则？是.
• 有关系吗？没有

将两者混为一谈并将各种无关信息纳入讨论只会使问题混乱.