返回这个而不是 void 有什么缺点吗？

发布于 2024-07-04 07:28:30 字数 689 浏览 8 评论 0原文

假设不是返回 void 方法，而是返回对该类的引用，即使它没有任何特定的语义意义。在我看来，它会给你更多关于如何调用方法的选择，允许你以类似流畅界面的风格使用它，而且我真的想不出任何缺点，因为你不需要做任何事情与返回值（甚至存储它）。

因此，假设您想要更新一个对象，然后返回其当前值。而不是说

myObj.Update();
var val = myObj.GetCurrentValue();

你可以将这两行组合起来说

var val = myObj.Update().GetCurrentValue();

编辑：我一时兴起问了下面的内容，回想起来，我同意这可能是不必要的并且复杂化，但是我关于返回的问题这而不是空站。

与此相关的是，你们认为让该语言包含一些新的语法糖怎么样：

var val = myObj.Update()<.GetCurrentValue();

该运算符的优先级较低，因此 myObj.Update() 将首先执行，然后在 myObj 上调用 GetCurrentValue() 而不是Update 的无效返回。

本质上，我想象一个运算符会说“在左侧第一个有效对象上调用运算符右侧的方法”。有什么想法吗？

原文

Say instead of returning void a method you returned a reference to the class even if it didn't make any particular semantic sense. It seems to me like it would give you more options on how the methods are called, allowing you to use it in a fluent-interface-like style and I can't really think of any disadvantages since you don't have to do anything with the return value (even store it).

So suppose you're in a situation where you want to update an object and then return its current value.
instead of saying

myObj.Update();
var val = myObj.GetCurrentValue();

you will be able to combine the two lines to say

var val = myObj.Update().GetCurrentValue();

EDIT: I asked the below on a whim, in retrospect, I agree that its likely to be unnecessary and complicating, however my question regarding returning this rather than void stands.

On a related note, what do you guys think of having the language include a new bit of syntactic sugar:

var val = myObj.Update()<.GetCurrentValue();

This operator would have a low order of precedence so myObj.Update() would execute first and then call GetCurrentValue() on myObj instead of the void return of Update.

Essentially I'm imagining an operator that will say "call the method on the right-hand side of the operator on the first valid object on the left". Any thoughts?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

极度宠爱 2024-07-11 07:28:30

我知道在 Java 中他们实际上正在考虑为 void 方法制定这种标准行为。如果你这样做，你就不需要额外的语法糖。

我能想到的唯一缺点是性能。但这很容易测量。我将在几分钟内回复您结果:-)

编辑：

返回引用比返回 void 慢一点..真是令人惊讶。所以这是唯一的缺点。调用函数时再打几下。

回复收藏 0 原文

睫毛上残留的泪 2024-07-11 07:28:30

我认为作为一般政策，它根本没有意义。这种方式的方法链接可以与正确定义的接口一起使用，但只有在具有语义意义时才是合适的。

你的例子是一个不合适的主要例子，因为它没有语义意义。

同样，对于一个正确设计的流畅界面来说，你的语法糖是不必要的。

流畅的接口或方法链接可以工作得很好，但需要仔细设计。

回复收藏 0 原文

萌化 2024-07-11 07:28:30

我看到的唯一缺点是它使 API 变得更加混乱。假设您有一些带有remove() 方法的集合对象，该方法通常会返回void。现在您想要返回对集合本身的引用。新签名看起来像：

public MyCollection remove(Object someElement)

仅查看签名，并不清楚您是否返回对同一实例的引用。也许 MyCollection 是不可变的，并且您正在返回一个新实例。在某些情况下，就像这里一样，您需要一些外部文档来澄清这一点。

我实际上很喜欢这个想法，并且我相信有人讨论过改造 Java7 中的所有 void 方法以返回对“this”的引用，但最终失败了。

The only disadvantage I can see is that it makes the API slightly more confusing. Let's say you have some collection object with a remove() method that would normally return void. Now you want to return a reference to the collection itself. The new signature would look like:

public MyCollection remove(Object someElement)

Just looking at the signature, it's not clear that you're returning a reference to the same instance. Maybe MyCollection is immutable and you're returning a new instance. In some cases, like here, you would need some external documentation to clarify this.

I actually like this idea, and I believe that there was some talk in retrofitting all void methods in Java7 to return a reference to 'this', but it ultimately fell through.

回复收藏 0 原文

紫竹語嫣☆ 2024-07-11 07:28:30

乍一看它可能看起来不错，但是为了获得一致的接口，您将需要所有方法都返回对此的引用（这有它自己的问题）。

假设你有一个类，它有两个方法 GetA（返回 this）和 GetB（返回另一个对象）：

那么你可以调用 obj.GetA().GetB()，但不能调用 obj.GetB().GetA()，这至少不会似乎不一致。

使用 Pascal（和 Visual Basic），您可以调用同一对象的多个方法。

与 obj 
    。得到（）; 
    .GetB(); 
  结束于；

此功能的问题在于，您很容易编写出比应有的更难理解的代码。另外添加一个新的操作员可能会让事情变得更加困难。

At first sight it may look good, but for a consistent interface you will need that all methods return a reference to this (which has it own problems).

Let say you have a class with two methods GetA which return this and GetB which return another object:

Then you can call obj.GetA().GetB(), but not obj.GetB().GetA(), which at least doesn't seems consistent.

With Pascal (and Visual Basic) you can call several methods of the same object.

with obj
  .GetA();
  .GetB();
end with;

The problem with this feature is that you easily can write code that is harder to understand than it should be. Also adding a new operator probably make it ever harder.

回复收藏 0 原文

何处潇湘 2024-07-11 07:28:30

NeXTSTEP Objective-C 框架曾经使用过这种模式。一旦分布式对象（基本上是远程过程调用）被添加到语言中，它就在该框架中停止了——返回 self 的函数必须是同步调用，因为分布式对象系统看到了返回类型并假设调用者需要知道函数的结果。

回复收藏 0 原文

浅笑轻吟梦一曲 2024-07-11 07:28:30

返回“self”或“this”是一种常见模式，有时称为“方法链接”< /a>. 至于你提出的语法糖，我不太确定。我不是 .NET 人，但它对我来说似乎并不是很有用。

回复收藏 0 原文

北渚 2024-07-11 07:28:30

这难道不是“流畅的接口”——就像 JQuery 使用的接口——是如何构建的吗？一个好处应该是代码可读性（尽管维基百科条目位于 http://en.wikipedia.org/ wiki/Fluent_interface 提到有些人发现它不可读）。另一个好处是代码简洁，您无需在 7 行代码中设置属性，然后在第 8 行中调用该对象的方法。

Martin Fowler（他在这里创造了这个术语 - http://martinfowler.com/bliki/FluentInterface.html) 说流畅的接口比方法链接有更多的内容，但是方法链接是与流畅的接口一起使用的常见技术。

编辑：
我实际上是回到这里编辑我的答案，并补充说，当我看到乔治的评论指出我确实忘记讨论这一点时，以任何可衡量的方式返回它而不是无效没有任何缺点。的问题。很抱歉最初的“毫无意义”的胡言乱语。