方法链——为什么它是一个好的实践方法，或者不是？

方法链可能对大多数情况来说只是一种新奇的东西，但我认为它有它的用处。一个例子可以在CodeIgniter活动记录的使用中找到：

$this->db->select('something')->from('table')->where('id', $id);

我认为这比下面的代码更加清晰易懂：

$this->db->select('something');
$this->db->from('table');
$this->db->where('id', $id);

这是很主观的；每个人都有自己的看法。

我通常不喜欢使用方法链，因为我认为它会降低代码的可读性。紧凑性经常被误解为可读性，但它们并不是相同的概念。如果你把所有的操作都写在一条语句里，那么虽然紧凑，但往往比分成多条语句来得难以阅读（难以跟进）。正如你所注意到的，除非你能保证所使用的方法的返回值相同，否则方法链将会带来困惑。

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

vs

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

2.)

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

vs

mondaySchedule = participant.getSchedule('monday');
mondaySchedule.saveTo('monday.file');

3.)

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

对比

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

如您所见，您几乎没有获得任何东西，因为您必须添加换行符以使单个语句更易读，并且必须添加缩进以明确您正在讨论不同的对象。如果我想使用基于缩进的语言，那么我会学习Python而不是这样做，更不用说大多数IDE将通过自动格式化代码来删除缩进了。
我认为这种链接可以有用的唯一场所就是在CLI中管道传输流或在SQL中连接多个查询。但是对于多个语句，它们都需要付出代价。但是，如果您想解决复杂的问题，则最终将使用这些方法并编写多个语句的代码，使用变量编写bash脚本和存储过程或视图。
关于DRY的解释：“避免重复知识（而不是重复文本）。”和“输入较少，甚至不要重复文本。”第一个解释是原则真正的含义，但第二个解释是常见的误解，因为许多人无法理解“系统内每个知识片段必须具有单一、明确、权威的表述”。第二个解释是为了紧凑而牺牲可读性，这在这种情况下会更糟。第一个解释在DDD中会被打破，当您在限界上下文之间复制代码时，因为在这种情况下解耦更加重要。

我认为主要的谬误是普遍认为这是一种面向对象的方法，而实际上它更像是一种函数式编程方法。
我使用它的主要原因是为了可读性和防止我的代码被变量淹没。
当别人说它会损害可读性时，我并不真正理解。它是我使用过的最简洁和连贯的编程形式之一。
此外，这样使用：
convertTextToVoice.LoadText("source.txt").ConvertToVoice("destination.wav");
是我通常使用它的方式。我不会使用它来链接x个参数。如果我想在方法调用中放入x个参数，我会使用params语法： public void foo(params object[] items)
并根据类型进行对象转换，或者根据您的用例使用数据类型数组或集合。

我同意，因此我改变了我的库中流畅接口的实现方式。

之前：

collection.orderBy("column").limit(10);

之后：

collection = collection.orderBy("column").limit(10);

在“before”实现中，函数修改了对象并以return this结尾。 我将实现更改为返回相同类型的新对象。 我做出此更改的原因是:

1. 返回值与函数无关，仅用于支持链接部分，根据OOP原则，它应该是一个void函数。

2. 系统库中的方法链接也是这样实现的（如linq或string）：

   myText = myText.trim().toUpperCase();
   

3. 原始对象保持不变，允许API用户决定如何处理它。它允许：

   page1 = collection.limit(10);
   page2 = collection.offset(10).limit(10);
   

4. 在构建对象时也可以使用复制实现：

   painting = canvas.withBackground('white').withPenSize(10);
   

   其中setBackground(color)函数更改实例并不返回任何值（正如它应该做的那样）。

5. 函数的行为更加可预测（见点1和2）。

6. 使用短变量名还可以减少代码混乱，而不会强制执行模型上的API。

   var p = participant; // 创建引用
   p.addSchedule(events[1]);p.addSchedule(events[2]);p.setStatus('attending');p.save()
   

结论：
我认为，使用return this实现的流畅接口是错误的。

有见解的回答

链式编程最大的缺点是读者很难理解每个方法如何影响原始对象（如果它确实影响），以及每个方法返回的类型是什么。

一些问题：

• 链中的方法是返回一个新对象还是改变同一个对象？
• 链中的所有方法是否都返回相同的类型？
• 如果不是，如何指示链中的类型何时更改？
• 最后一个方法返回的值是否可以安全地丢弃？

在大多数语言中，调试链式编程确实更难。即使链中的每个步骤都在自己的行上（这有点违背了链式编程的初衷），检查每个步骤返回的值也可能很困难，特别是对于非变异方法。

编译时间可能会更慢，具体取决于语言和编译器，因为表达式可能更加复杂。

我认为，像任何东西一样，链式编程是一个好的解决方案，可以在某些情况下非常方便。它应该谨慎使用，理解其影响，并将链元素的数量限制在几个。

优点:

1. 简洁，但可以优雅地在一行中放入更多内容。
2. 有时可以避免使用变量，这可能偶尔会很有用。
3. 性能可能更好。

缺点:

1. 您正在实现返回值，实际上是向对象上的方法添加功能，而这些方法并不真正属于它们所要执行的操作的一部分。它返回了您已经拥有的内容，纯粹是为了节省几个字节。
2. 当一个链条导致另一个链条时，它会隐藏上下文切换。使用getter可以获得此功能，但很明显上下文切换的情况比较清晰。
3. 跨多行链接看起来很丑，无法很好地处理缩进，并且可能会引起一些运算符处理混淆（特别是在具有ASI的语言中）。
4. 如果要开始返回其他有用的链接方法，请修复它可能会更加困难或遇到更多问题。
5. 您正在将控制权转移到一个通常不会转移控制权的实体，仅出于方便考虑，即使在严格类型的语言中，由此引起的错误也不一定总是可以检测到。
6. 性能可能更差。

总的来说:

一个好的方法是一般情况下不使用链接，直到出现特定模块或特定情况可以特别适用它。

链接在某些情况下会严重影响可读性，尤其是考虑到第1点和第2点的时候。
有时会被误用，例如代替其他方法（比如传递数组）或以奇怪的方式混合使用方法（parent.setSomething().getChild().setSomething().getParent().setSomething()）。

Linq查询是方法链接的一个很好的例子，其中典型的查询看起来像下面这样：

lstObjects
  .Where(...)
  .Select(...)
  .OrderBy(...)
  .ThenBy(...)
  .ToList();

在我看来，这种方法非常直观，避免了不必要的临时变量来存储部分结果，而这些结果可能并不是我们真正感兴趣的。
还有一个更微妙的问题需要注意，那就是使用“ThenBy”扩展方法，该方法只能在调用“OrderBy”或“OrderByDescending”方法之后调用。这意味着在此处也维护了一个内部状态，该状态确定是否可以调用ThenBy。就像在这个查询中一样，有些情况下客户端应用程序可能不想将内部状态存储在临时变量中，而只对最终结果感兴趣。
因此，在编写库时，如果我们想提供一个API，以便按照特定顺序执行某个操作集，则允许方法链接会使库的使用更加直观。

嗯，我认为方法链的最重要优势是您不必重复调用同一对象来执行连续操作。您必须使用它。

这里完全错过了重点，方法链允许DRY。它是“with”（在某些语言中实现不佳）的有效替代品。

A.method1().method2().method3(); // one A

A.method1();
A.method2();
A.method3(); // repeating A 3 times

这很重要的原因与DRY（Don't Repeat Yourself）的原则相同；如果A被证明是一个错误，而这些操作需要在B上执行，你只需要在一个地方更新，而不是三个地方。

实际上，在这种情况下，这种优势很小。但仍然有一点少打字，更加健壮（DRY），我会接受它。

在静态类型语言中（缺少auto或等效功能），这可以避免实现者必须声明中间结果的类型。

import Participant
import Schedule

Participant participant = new Participant()
... snip...
Schedule s = participant.getSchedule(blah)
s.saveTo(filename)

对于更长的链，您可能需要处理几种不同的中间类型，您需要声明每个类型。

我相信这种方法确实是在Java中发展起来的，其中a）所有函数调用都是成员函数调用，b）需要显式类型。当然，在某些情况下，这里存在一个折衷，即丧失一些明确性，但在某些情况下，有些人认为这是值得的。