方法链接（流畅的接口）——为什么它是一个好的实践，或者不是一个好的实践？

Question

方法链是对象方法返回对象本身以便调用结果的做法另一种方法。 像这样：

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

这似乎被认为是一个很好的实践，因为它产生可读的代码，或“流畅的界面”。 然而，对我来说，它似乎破坏了面向对象本身隐含的对象调用符号 - 生成的代码并不代表对先前方法的结果执行操作，这就是面向对象代码的方式通常期望起作用：

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

这种差异设法为“调用结果对象”的点表示法创建两种不同的含义：在链接的上下文中，上面的示例将被理解为保存参与者对象，即使该示例实际上旨在保存 getSchedule 接收到的调度对象。

我知道这里的区别在于被调用的方法是否应该返回某些内容（在这种情况下它将返回被调用的对象本身以进行链接）。 但这两种情况无法从符号本身区分，只能从被调用方法的语义区分。 当不使用方法链接时，我总是可以知道方法调用对与前一个调用的结果相关的东西进行操作 - 使用链接，这个假设就被打破了，我必须在语义上处理整个链了解被调用的实际对象到底是什么。 例如：

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

最后两个方法调用引用 getSocialStream 的结果，而前面的调用引用参与者。 也许在上下文发生变化的地方实际编写链是不好的做法（是吗？），但即便如此，您也必须不断检查看起来相似的点链实际上是否保留在相同的上下文中，或者只对结果起作用。

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

旁注：我理解这个问题可以被解读为掩盖为问题的意见陈述。 然而事实并非如此——我真的想理解为什么链接被认为是好的实践，以及我认为它破坏了固有的面向对象表示法的错误在哪里。

Answer 1

只是我的2分钱；

方法链接使调试变得棘手：
- 你不能把断点放在一个简洁的点上，这样你就可以在你想要的地方暂停程序
- 如果这些方法之一抛出异常，并且您得到行号，则您不知道“链”中的哪个方法导致了问题。

我认为总是写出非常短而简洁的行通常是一个很好的做法。 每一行应该只调用一个方法。 喜欢更多的线路而不是更长的线路。

编辑：评论提到方法链接和换行是分开的。 那是真实的。 不过，根据调试器的不同，可能会也可能不会在语句中间放置断点。 即使可以，使用带有中间变量的单独行也可以为您提供更大的灵活性，并且您可以在“监视”窗口中检查一大堆值，这有助于调试过程。

Answer 2

我同意这是主观的。 在大多数情况下，我避免方法链接，但最近我还发现了一种情况，它是正确的事情 - 我有一个方法接受大约 10 个参数，并且需要更多参数，但大多数时候你只需要指定一个很少。 通过覆盖，这很快变得非常麻烦。 相反，我选择了链接方法：

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

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

关键是 - 在 99% 的情况下，如果没有方法链接，您可能可以做得同样好甚至更好。 但对于 1% 的人来说，这是最好的方法。

Answer 3

就我个人而言，我更喜欢仅作用于原始对象的链接方法，例如设置多个属性或调用实用程序类型的方法。

foo.setHeight(100).setWidth(50).setColor('#ffffff');
foo.moveTo(100,100).highlight();

在我的示例中，当一个或多个链接方法返回除 foo 之外的任何对象时，我不会使用它。 虽然从语法上讲，只要对链中的对象使用正确的 API，就可以链接任何内容，但恕我直言，更改对象会降低可读性，并且如果不同对象的 API 有任何相似之处，可能会造成真正的混乱。 如果您在最后执行一些非常常见的方法调用（.toString()、.print()，等等），您最终将针对哪个对象进行操作？ 随意阅读代码的人可能不会发现它将是链中隐式返回的对象而不是原始引用。

链接不同的对象也可能导致意外的空错误。 在我的示例中，假设 foo 有效，所有方法调用都是“安全的”（例如，对 foo 有效）。 在OP的示例中：

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

...不能保证（作为查看代码的外部开发人员）getSchedule实际上会返回一个有效的非空调度对象。 此外，调试这种类型的代码通常要困难得多，因为许多 IDE 不会在调试时将方法调用评估为您可以检查的对象。 IMO，任何时候您可能需要一个对象来检查以进行调试，我更喜欢将其放在显式变量中。

Answer 4

Martin Fowler 在这里进行了很好的讨论：

方法链

何时使用

方法链接可以带来很多好处
内部 DSL 的可读性
结果几乎变成了
某些情况下内部 DSL 的同义词
头脑。 方法链接是最好的，
然而，当它结合使用时
与其他功能组合。

方法链特别重要
对像parent::=这样的语法有效
（这个|那个）*。 不同的用途
方法提供了可读的方式
看看接下来会出现哪个论证。
类似地，可选参数可以是
使用方法可以轻松跳过
连锁。 强制性条款清单，
例如parent::=第一第二不
与基本形式配合得很好，
虽然它可以得到很好的支持
使用渐进式界面。 大多数
我更喜欢嵌套函数的时候
对于这种情况。

Method 最大的问题
链接是整理问题。
虽然有解决方法，但通常
如果你遇到这个你会更好
使用嵌套函数。 嵌套
功能也是一个更好的选择，如果
你陷入了困境
上下文变量。

Answer 5

在我看来，方法链有点新颖。 当然，它看起来很酷，但我没有看到它有任何真正的优点。

怎么样：

someList.addObject("str1").addObject("str2").addObject("str3")

比什么更好：

someList.addObject("str1")
someList.addObject("str2")
someList.addObject("str3")

例外可能是当 addObject() 返回一个新对象时，在这种情况下，未链接的代码可能会有点麻烦，例如：

someList = someList.addObject("str1")
someList = someList.addObject("str2")
someList = someList.addObject("str3")

---

编辑：我对此的看法在过去 10 年里发生了变化。 对于可变对象，我仍然没有看到太多好处，尽管它对于避免一点点重复很有用。 但现在我更喜欢不变性，方法链接是我进行非破坏性更新的首选方式，我一直使用这种方式。

Answer 6

这是危险的，因为您可能依赖比预期更多的对象，就像您的调用返回另一个类的实例一样：

我将举一个例子：

foodStore 是一个由您拥有的许多食品商店组成的对象。
foodstore.getLocalStore() 返回一个对象，该对象保存距离参数最近的商店的信息。 getPriceforProduct(anything) 是该对象的方法。

因此，当您调用 foodStore.getLocalStore(parameters).getPriceforProduct(anything) 时，

您不仅依赖于 FoodStore，还依赖于 LocalStore。

如果 getPriceforProduct(anything) 发生变化，您不仅需要更改 FoodStore，还需要更改调用链式方法的类。

您应该始终以类之间的松散耦合为目标。

话虽这么说，我个人喜欢在 Ruby 编程时将它们链接起来。

Answer 7

许多人使用方法链作为一种方便的形式，而不是考虑任何可读性问题。 如果方法链涉及对同一个对象执行相同的操作，那么它是可以接受的 - 但前提是它确实增强了可读性，而不仅仅是为了编写更少的代码。

不幸的是，许多人按照问题中给出的示例使用方法链接。 虽然它们仍然可读，但不幸的是它们导致了多个类之间的高度耦合，因此这是不可取的。

Answer 8

方法链可以允许直接在 Java 中设计高级 DSL。 本质上，您至少可以对这些类型的 DSL 规则进行建模：

1. SINGLE-WORD
2. PARAMETERISED-WORD parameter
3. WORD1 [ OPTIONAL-WORD]
4. WORD2 { WORD-CHOICE-A | WORD-CHOICE-B }
5. WORD3 [ , WORD3 ... ]

这些规则可以使用这些接口来实现

// Initial interface, entry point of the DSL
interface Start {
  End singleWord();
  End parameterisedWord(String parameter);
  Intermediate1 word1();
  Intermediate2 word2();
  Intermediate3 word3();
}

// Terminating interface, might also contain methods like execute();
interface End {}

// Intermediate DSL "step" extending the interface that is returned
// by optionalWord(), to make that method "optional"
interface Intermediate1 extends End {
  End optionalWord();
}

// Intermediate DSL "step" providing several choices (similar to Start)
interface Intermediate2 {
  End wordChoiceA();
  End wordChoiceB();
}

// Intermediate interface returning itself on word3(), in order to allow for
// repetitions. Repetitions can be ended any time because this interface
// extends End
interface Intermediate3 extends End {
  Intermediate3 word3();
}

通过这些简单的规则，您可以直接在 Java 中实现复杂的 DSL，例如 SQL，就像 jOOQ，我创建的一个库。 请参阅取自 我的博客在这里：

create().select(
    r1.ROUTINE_NAME,
    r1.SPECIFIC_NAME,
    decode()
        .when(exists(create()
            .selectOne()
            .from(PARAMETERS)
            .where(PARAMETERS.SPECIFIC_SCHEMA.equal(r1.SPECIFIC_SCHEMA))
            .and(PARAMETERS.SPECIFIC_NAME.equal(r1.SPECIFIC_NAME))
            .and(upper(PARAMETERS.PARAMETER_MODE).notEqual("IN"))),
                val("void"))
        .otherwise(r1.DATA_TYPE).as("data_type"),
    r1.NUMERIC_PRECISION,
    r1.NUMERIC_SCALE,
    r1.TYPE_UDT_NAME,
    decode().when(
    exists(
        create().selectOne()
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.notEqual(r1.SPECIFIC_NAME))),
        create().select(count())
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.lessOrEqual(r1.SPECIFIC_NAME)).asField())
    .as("overload"))
.from(r1)
.where(r1.ROUTINE_SCHEMA.equal(getSchemaName()))
.orderBy(r1.ROUTINE_NAME.asc())
.fetch()

另一个很好的例子是jRTF，有点DSL 设计用于直接用 Java 生成 RTF 文档。 一个例子：

rtf()
  .header(
    color( 0xff, 0, 0 ).at( 0 ),
    color( 0, 0xff, 0 ).at( 1 ),
    color( 0, 0, 0xff ).at( 2 ),
    font( "Calibri" ).at( 0 ) )
  .section(
        p( font( 1, "Second paragraph" ) ),
        p( color( 1, "green" ) )
  )
).out( out );

Answer 9

链接的好处
即，我喜欢使用它的地方

我没有看到提及的链接的一个好处是能够在变量初始化期间或将新对象传递给方法时使用它，不确定这是否是不好的做法。

我知道这是人为的示例，但假设您有以下类，

Public Class Location
   Private _x As Integer = 15
   Private _y As Integer = 421513

   Public Function X() As Integer
      Return _x
   End Function
   Public Function X(ByVal value As Integer) As Location
      _x = value
      Return Me
   End Function

   Public Function Y() As Integer
      Return _y
   End Function
   Public Function Y(ByVal value As Integer) As Location
      _y = value
      Return Me
   End Function

   Public Overrides Function toString() As String
      Return String.Format("{0},{1}", _x, _y)
   End Function
End Class

Public Class HomeLocation
   Inherits Location

   Public Overrides Function toString() As String
      Return String.Format("Home Is at: {0},{1}", X(), Y())
   End Function
End Class

并说您无权访问基类，或者说默认值是动态的，基于时间等。是的，您可以实例化，然后更改值但这可能会变得很麻烦，特别是如果您只是将值传递给方法时：

  Dim loc As New HomeLocation()
  loc.X(1337)
  PrintLocation(loc)

但这不是更容易阅读吗：

  PrintLocation(New HomeLocation().X(1337))

或者，类成员怎么样？

Public Class Dummy
   Private _locA As New Location()
   Public Sub New()
      _locA.X(1337)
   End Sub
End Class

vs

Public Class Dummy
   Private _locC As Location = New Location().X(1337)
End Class

这就是我使用链接的方式，通常我的方法仅用于配置，因此它们只有 2 行长，设置一个值，然后 Return Me。 对我们来说，它已经将难以阅读和理解的大行代码清理成一行，读起来就像一个句子。
类似于

New Dealer.CarPicker().Subaru.WRX.SixSpeed.TurboCharged.BlueExterior.GrayInterior.Leather.HeatedSeats

Vs 的东西

New Dealer.CarPicker(Dealer.CarPicker.Makes.Subaru
                   , Dealer.CarPicker.Models.WRX
                   , Dealer.CarPicker.Transmissions.SixSpeed
                   , Dealer.CarPicker.Engine.Options.TurboCharged
                   , Dealer.CarPicker.Exterior.Color.Blue
                   , Dealer.CarPicker.Interior.Color.Gray
                   , Dealer.CarPicker.Interior.Options.Leather
                   , Dealer.CarPicker.Interior.Seats.Heated)

链接的损害
即，在我不喜欢使用它的地方，

当有很多参数要传递给例程时，我不使用链接，主要是因为行变得很长，并且正如OP提到的，当你'重新调用其他类的例程以传递给链接方法之一。

还担心例程会返回无效数据，因此到目前为止，我仅在返回被调用的同一实例时才使用链接。 正如所指出的，如果在类之间进行链接，则会增加调试难度（哪一个返回 null？），并且会增加类之间的依赖耦合。

结论

就像生活中的一切和编程一样，链接既不好也不坏，如果您可以避免不好的事情，那么链接可以带来很大的好处。

我尝试遵守这些规则。

1. 尽量不要在类之间链接
2. 专门为
   链接
3. 在链接中只做一件事
   当
4. 当它提高可读性时使用它
5. 它使代码更简单时使用它

Answer 10

这似乎有点主观。

在我看来，方法链接本身并不是坏事或好事。

可读性是最重要的。

（还要考虑到，如果发生变化，链接大量方法会使事情变得非常脆弱）

Answer 11

我通常讨厌方法链接，因为我认为它会降低可读性。 紧凑性经常与可读性混淆，但它们不是同一个术语。 如果您在一条语句中完成所有操作，那么这会很紧凑，但大多数情况下，它的可读性（更难遵循）比在多个语句中执行的要差。 正如您所注意到的，除非您不能保证所使用方法的返回值相同，否则方法链将成为混乱的根源。

1.)

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'));

vs

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 打破，因为松散耦合在这种情况下更为重要。

Answer 12

对于大多数情况来说，方法链可能只是一个新鲜事物，但我认为它有它的地位。 可以在 CodeIgniter 的 Active Record 使用 中找到一个示例：

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

这看起来更干净（并且在我看来，这更有意义）比：

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

它确实是主观的； 每个人都有自己的看法。

Answer 13

我认为主要的谬误是认为这是一种面向对象的方法，而实际上它更多的是一种函数式编程方法而不是其他方法。

我使用它的主要原因是为了提高可读性并防止我的代码被变量淹没。

当其他人说这会损害可读性时，我真的不明白他们在说什么。 这是我使用过的最简洁、最有凝聚力的编程形式之一。

另外：

convertTextToVoice.LoadText("source.txt").ConvertToVoice("destination.wav");

是我通常使用它的方式。 我通常不使用它来链接 x 个参数。 如果我想在方法调用中放入 x 个参数，我将使用 params 语法：

public void foo(params object[] items)

并根据对象进行强制转换根据类型或仅使用数据类型数组或集合，具体取决于您的用例。

Answer 14

我同意，因此我改变了在我的库中实现流畅界面的方式。

之前：

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

之后：

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

在“之前”实现中，函数修改了对象并以 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 = 参与者；   // 创建一个引用 
     p.addSchedule(events[1]);p.addSchedule(events[2]);p.setStatus('参加');p.save() 
     

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

Answer 15

自以为是的答案

链接的最大缺点是，读者可能很难理解每个方法如何影响原始对象（如果会影响），以及每个方法返回什么类型。

一些问题：

• 链中的方法是否返回一个新对象，或者同一个对象发生了变化？
• 链中的所有方法都返回相同的类型吗？
• 如果不是，当链中的类型发生变化时如何指示？
• 最后一个方法返回的值可以安全地丢弃吗？

在大多数语言中，使用链接确实会使调试变得更加困难。 即使链中的每个步骤都在自己的行上（这违背了链接的目的），也很难检查每个步骤之后返回的值，特别是对于非变异方法。

根据语言和编译器的不同，编译时间可能会更慢，因为解析表达式可能要复杂得多。

我相信，就像所有事情一样，链接是一个很好的解决方案，在某些情况下可以很方便。 应谨慎使用，了解其含义，并将链元素的数量限制在少数。

Answer 16

优点：

1. 它很简洁，但允许您优雅地将更多内容放入一行中。
2. 有时您可以避免使用变量，这有时可能很有用。
3. 它可能会表现得更好。

坏处：

1. 您正在实现返回，本质上是向对象的方法添加功能，而这并不是这些方法真正要做的事情的一部分。 它返回你已经拥有的东西纯粹是为了节省几个字节。
2. 当一条链指向另一条链时，它会隐藏上下文切换。 您可以使用 getter 来获取此信息，除非上下文切换时非常清楚。
3. 多行链接看起来很难看，不能很好地处理缩进，并且可能会导致某些操作员处理混乱（尤其是在具有 ASI 的语言中）。
4. 如果您想开始返回对链式方法有用的其他内容，那么您可能会更难修复它或遇到更多问题。
5. 您将控制权转移到通常不会纯粹为了方便而转移到的实体，即使在严格类型语言中，也无法始终检测到由此引起的错误。
6. 它的表现可能会更差。

一般：

一个好的方法是一般不要使用链接，除非出现情况或特定模块特别适合它。

在某些情况下，链接可能会严重损害可读性，尤其是在权衡第 1 点和第 2 点时。

有时它可能会被滥用，例如代替另一种方法（例如传递数组）或以奇怪的方式混合方法（parent.setSomething() .getChild().setSomething().getParent().setSomething())。

Answer 17

这里完全忽略的一点是，方法链允许DRY 。 它是“with”的有效替代（在某些语言中实现得很差）。

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

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

这与 DRY 始终很重要的原因相同； 如果A结果出错，而这些操作需要在B上执行，则只需更新1处，而不是3处。

实际上，在这种情况下优势很小。 不过，少一点打字，多一点健壮（DRY），我会接受的。

Answer 18

在类型化语言（缺少 auto 或等效语言）中，这使实现者不必声明中间结果的类型。

import Participant
import Schedule

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

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

我相信这种方法确实是在 Java 中开发的，其中 a) 所有函数调用都是成员函数调用，b) 需要显式类型。 当然，这里需要进行权衡，失去一些明确性，但在某些情况下，有些人发现这是值得的。

Answer 19

Linq 查询是方法链接的一个很好的示例，其中典型的查询如下所示：

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

在我看来，这是非常直观的，并且避免了不必要的临时变量来存储人们可能几乎不感兴趣的部分结果。

需要注意的一件更微妙的事情是“ThenBy”扩展方法的使用，只有在调用“OrderBy”或“OrderByDescending”方法之后才能调用该方法。 这意味着这里还维护一个内部状态，它决定是否可以调用 thenBy。 就像在此查询中一样，在某些情况下，客户端应用程序可能对将内部状态存储在临时变量中不感兴趣，而可能只对最终结果感兴趣。

因此，在编写库时，如果我们想要提供一个 API，让其感觉按特定顺序执行一组特定操作，那么允许方法链接将使库的使用更加直观。

Answer 20

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