方法链 - 为什么这是一个好习惯，或者不是? [英] Method chaining - why is it a good practice, or not?

问题描述

方法链 是对象方法返回对象本身以便结果被调用另一种方法.像这样:

Method chaining is the practice of object methods returning the object itself in order for the result to be called for another method. Like this:

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

这似乎被认为是一个很好的做法，因为它产生了可读的代码，或流畅的界面".然而，对我来说，它似乎打破了面向对象本身隐含的对象调用符号 - 结果代码并不表示对先前方法的 result 执行操作，这就是面向对象代码的方式一般预期工作:

This seems to be considered a good practice, since it produces readable code, or a "fluent interface". However, to me it instead seems to break the object calling notation implied by the object orientation itself - the resulting code does not represent performing actions to the result of a previous method, which is how object oriented code is generally expected to work:

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

这种差异设法为调用结果对象"的点符号创建了两种不同的含义:在链接的上下文中，上面的示例将读取为保存 participant 对象，即使该示例实际上是为了保存 getSchedule 接收到的调度对象.

This difference manages to create two different meanings for the dot-notation of "calling the resulting object": In the context of chaining, the above example would read as saving the participant object, even though the example is in fact intended to save the schedule object received by getSchedule.

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

I understand that the difference here is whether the called method should be expected to return something or not (in which case it would return the called object itself for chaining). But these two cases are not distinguishable from the notation itself, only from the semantics of the methods being called. When method chaining is not used, I can always know that a method call operates on something related to the result of the previous call - with chaining, this assumption breaks, and I have to semantically process the whole chain to understand what the actual object being called really is. For example:

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

最后两个方法调用是指 getSocialStream 的结果，而前面的方法是指参与者.也许在上下文发生变化的情况下实际编写链是不好的做法(是吗?)，但即便如此，您也必须不断检查看起来相似的点链是否实际上保持在相同的上下文中，或者只处理结果.

There the last two method calls refer to the result of getSocialStream, whereas the ones before refer to the participant. Maybe it's bad practice to actually write chains where the context changes (is it?), but even then you'll have to constantly check whether dot-chains that look similar are in fact keep within the same context, or only work on the result.

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

To me it appears that while method chaining superficially does produce readable code, overloading the meaning of the dot-notation only results in more confusion. As I don't consider myself a programming guru, I assume the fault is mine. So: What am I missing? Do I understand method chaining somehow wrong? Are there some cases where method chaining is especially good, or some where it's especially bad?

旁注:我理解这个问题可以理解为一个被掩饰为问题的意见陈述.然而，事实并非如此 - 我真的很想了解为什么链接被认为是一种很好的做法，以及我认为它打破了固有的面向对象表示法的错误在哪里.

Sidenote: I understand this question could be read as a statement of opinion masked as a question. It, however, isn't - I genuinely want to understand why chaining is considered good practice, and where do I go wrong in thinking it breaks the inherent object-oriented notation.

推荐答案

我同意这是主观的.在大多数情况下，我避免了方法链接，但最近我也发现了一个正确的例子 - 我有一个方法可以接受 10 个参数，并且需要更多参数，但大多数时候你只需要指定一个很少.随着覆盖这变得非常麻烦非常快.相反，我选择了链接方法:

I agree that this is subjective. For the most part I avoid method chaining, but recently I also found a case where it was just the right thing - I had a method which accepted something like 10 parameters, and needed more, but for the most time you only had to specify a few. With overrides this became very cumbersome very fast. Instead I opted for the chaining approach:

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

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

The method chaining approach was optional, but it made writing code easier (especially with IntelliSense). Mind you that this is one isolated case though, and is not a general practice in my code.

重点是 - 在 99% 的情况下，如果没有方法链，您可能会做得同样好甚至更好.但有 1% 的人认为这是最好的方法.

The point is - in 99% cases you can probably do just as well or even better without method chaining. But there is the 1% where this is the best approach.

这篇关于方法链 - 为什么这是一个好习惯，或者不是?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！