问题
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?
回答1:
I know in Java they're actually thinking about making this standard behaviour for void methods. If you do that you don't need the extra syntactic sugar.
The only downside I can think of is performance. But that's easilly measured. I'll get back to you with the results in a few minutes :-)
Edit:
Returning a reference is a bit slower than returning void .. what a surprise. So that's the only downside. A few more ticks when calling your function.
回答2:
I think as a general policy, it simply doesn't make sense. Method chaining in this manner works with a properly defined interface but it's only appropriate if it makes semantic sense.
Your example is a prime one where it's not appropriate, because it makes no semantic sense.
Similarly, your syntactic sugar is unnecessary with a properly designed fluent interface.
Fluent interfaces or method chaining can work very well, but need to be designed carefully.
回答3:
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.
回答4:
Isn't this how "fluent interfaces" - like those that JQuery utilizes - are built? One benefit is supposed to be code readability (though the wikipedia entry at http://en.wikipedia.org/wiki/Fluent_interface mentions that some find it NOT readable). Another benefit is in code terseness, you lose the need to set properties in 7 lines of code and then call a method on that object in the 8th line.
Martin Fowler (who coined the term here - http://martinfowler.com/bliki/FluentInterface.html) says that there is more to fluent interfaces than method chaining, however method chaining is a common technique to use with fluent interfaces.
EDIT: I was actually coming back here to edit my answer and add that there is no disadvantage to returning this instead of void in any measurable way, when I saw George's comment pointing out that I did forget to discuss the point of the question. Sorry for the initial "pointless" rambling.
回答5:
Returning "self" or "this" is a common pattern, sometimes referred to as "method chaining". As for your proposed syntax sugar, I'm not so sure. I'm not a .NET guy, but it doesn't seem terribly useful to me.
回答6:
The NeXTSTEP Objective-C framework used to use this pattern. It was discontinued in that framework once distributed objects (remote procedure calls, basically) were added to the language—a function that returned self had to be a synchronous invocation, since the distributed object system saw the return type and assumed that the caller would need to know the result of the function.
回答7:
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.
来源：https://stackoverflow.com/questions/57140/is-there-any-disadvantage-to-returning-this-instead-of-void