Return "this" in java instead of cloning objects.(fluffyelephant.com)
fluffyelephant.com
Return "this" in java instead of cloning objects.
http://fluffyelephant.com/2011/06/return-this/
4 comments
Only useful if you do not mind your objects being mutable.
otherwise:
otherwise:
string name1 = "Andrew Ducker";
string name2 = name1;
name1.toUpper();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".
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).
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).
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.
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.
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...
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://stackoverflow.com/questions/5007355/builder-pattern-i...
https://manuelselva.wordpress.com/2010/04/09/effective-java-...