Return "this" in java instead of cloning objects.
fluffyelephant.com
fluffyelephant.com
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-...
otherwise:
string name1 = "Andrew Ducker";
string name2 = name1;
name1.toUpper();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).
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.