

Return "this" in java instead of cloning objects. - hmottestad
http://fluffyelephant.com/2011/06/return-this/

======
asymptotic
The idea of chained calls all returning this forms the basis of the
phenomenally useful Builder Pattern, from Bloch's "Effective Java".

There are three main reasons for using the Builder Pattern:

1) Allows for "constructor-like" calls to functions that don't necessarily
share the name of the class.

2) Allows for complex, multi-parameter "constructor-like" calls without
needing to make one massive function call.

3) Allows intermediate argument checking on particular constructor arguments,
and allows sane optional constructor arguments.

(I find this pattern very useful).

See:

[http://rwhansen.blogspot.com/2007/07/theres-builder-
pattern-...](http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-
joshua.html)

[http://stackoverflow.com/questions/5007355/builder-
pattern-i...](http://stackoverflow.com/questions/5007355/builder-pattern-in-
effective-java)

[https://manuelselva.wordpress.com/2010/04/09/effective-
java-...](https://manuelselva.wordpress.com/2010/04/09/effective-java-2nd-
edition-builder-pattern-in-eclipse/)

------
AndrewDucker
Only useful if you do not mind your objects being mutable.

otherwise:

    
    
      string name1 = "Andrew Ducker";
      string name2 = name1;
      name1.toUpper();

means that name2 is now also "ANDREW DUCKER" when we quite possibly didn't
want it to be.

~~~
hmottestad
Yes. In such a case you would need to clone the object. Having toUpper() clone
by default is wasteful if you don't need a clone. Hence using "return this".

~~~
AndrewDucker
And I would argue that the reason that C# and Java have both gone for making
strings immutable is that it is less confusing.

I value code that's less confusing over code that allocates extra objects
(largely because the last time I wrote some simple benchmarking code I could
allocate multiple millions of an object in a second).

~~~
mullr
I'm not sure if it's really less confusing. I once spent about an hour
struggling with string.Replace in C# before I bothered to read the
documentation. Falls into the 'gotcha' bucket in my mind.

Now, I'm pretty sure that strings are interned in C#, so making them immutable
makes a lot of sense from that perspective. It's just that the language
encourages mutable state in so many other areas that it's a bit of a mental
shift when you have to deal with strings. In Java... afaik strings aren't
interned by default, so I can't really argue for immutability there.

The original author's argument for method chaining feels like a separate case
altogether. Really it's primarily used when building embedded DSLs in these
languages. In that case, standard semantics be damned; do what you need to to
make the code look how you want.

------
sausagefeet
I totally thought this post was going to be about methods just recording what
the user wanted to do in a list and then have an apply method at the end. I'm
not sure why I thought that...

------
slifty
Taking a lesson from jQuery I see.

~~~
TNO
Fluent interfaces predate jQuery

