方法链接-为什么这是一个好习惯？

Question

方法链接 是对象方法返回对象本身以使结果被另一个方法调用的实践。像这样：

participant.addSchedule(events[1]).addSchedule(events[2]).setStatus('attending').save()

这似乎被认为是一种好习惯，因为它会产生可读的代码或“流畅的界面”。但是，对我而言，它似乎打破了面向对象本身所隐含的对象调用表示法-生成的代码不代表对先前方法的结果执行的动作，通常这是面向对象的代码的工作方式：

participant.getSchedule('monday').saveTo('monnday.file')

这种差异设法为“调用结果对象”的点标记创建了两种不同的含义：在链接的上下文中，以上示例将被视为保存参与者对象，即使该示例实际上旨在保存计划表也是如此。 getSchedule接收的对象。

我知道这里的区别在于是否应期望被调用方法返回某些内容（在这种情况下，它将返回被调用对象本身进行链接）。但是，这两种情况与符号本身并没有区别，仅与被调用方法的语义相区别。当不使用方法链接时，我总是可以知道，方法调用是在与上次调用的结果相关的操作上进行的-通过链接，这种假设会中断，并且我必须在语义上处理整个链，以了解实际对象是什么叫真的是。例如：

participant.attend(event).setNotifications('silent').getSocialStream('twitter').postStatus('Joining '+event.name).follow(event.getSocialId('twitter'))

那里的最后两个方法调用引用了getSocialStream的结果，而之前的方法调用引用了参与者。实际在上下文发生变化的地方写链可能不是一个好习惯（是吗？），但是即使如此，您也必须不断检查看起来相似的点链实际上是否在同一个上下文中，或者仅在结果上起作用。

在我看来，虽然表面上的方法链接确实会产生可读的代码，但是点符号含义的重载只会导致更多的混乱。由于我不认为自己是编程专家，所以我认为这是我的错。所以：我想念什么？我是否理解方法链接有些错误？在某些情况下方法链接特别好，还是在某些情况下特别不好？

旁注：我理解这个问题可以理解为掩盖为问题的意见陈述。但是，它不是-我真正地想理解为什么链被认为是一种好习惯，而在认为链打破了固有的面向对象表示法的地方我犯了错。

Answer 1

我同意这是主观的。在大多数情况下，我避免使用方法链接，但是最近我还发现了一种情况，那就是正确的做法-我有一个方法可以接受10个参数之类的参数，并且需要更多的参数，但是在大多数情况下，您只需要指定一个很少。有了覆盖，这很快就变得非常麻烦。相反，我选择了链接方法：

MyObject.Start()
    .SpecifySomeParameter(asdasd)
    .SpecifySomeOtherParameter(asdasd)
    .Execute();

方法链接方法是可选的，但是它使编写代码更容易（尤其是使用IntelliSense）。请注意，这只是一个孤立的案例，并不是我的代码中的常规做法。

关键是-在99％的情况下，无需方法链接就可以做得甚至更好。但这是1％的最佳方法。