Timeline for Simple builder pattern implementation for building immutable objects
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 30, 2019 at 15:39 | comment | added | giannis christofakis |
That's amazing. You entirely eliminated the new keyword, but isn't this like you have a builder to create a Builder ? Moreover, I really like the idea of @Thijs Riezebeek to re-use the Builder instance, any thoughts on that ?
|
|
| May 5, 2016 at 5:06 | comment | added | bowmore | A mutable object's fields cannot all be final. If you define a class whose instances will be shared across threads, then making it immutable and have final fields is the best option (if that is possible). But even a mutable object can be shared between threads, yet you'll need explicit synchronization to pull that off. Some objects are not meant to be shared across threads, and all of this is not even a concern. Encapsulation is always a good design choice; if you can do without an accessor, leave it out. If you can make a field final, make it final. | |
| May 5, 2016 at 0:54 | comment | added | Levent Divilioglu | @bowmore Then it seems a good idea to use final keyword for mutable objects, isn't it? Especially if we want the references not to be updated, we should remove the getters and use final keyword with the reference fields in order to remove the visibility for thread-safety? Please correct me If I'm on the wrong direction. | |
| May 5, 2016 at 0:50 | comment | added | bowmore | @LeventDivilioglu "Final fields can’t be modified (although the objects they refer to can be modified if they are mutable), but they also have special semantics under the Java Memory Model." More specifically, an object with only final fields can be safely published and shared, through any mechanism. Without the final modifiers the same Object must be safely published (but can be shared without further synchronization). So omitting final on its fields would make Person, in this question, an object we should make sure to publish safely. (see Java Concurrency in Practice for a full explanation) | |
| May 4, 2016 at 21:11 | comment | added | Levent Divilioglu | @bowmore Can you tell & explain a little bit more about usage of final for the point of thread-safety ? | |
| May 4, 2016 at 11:25 | comment | added | bowmore | Removing final from the Person fields does mean that some visibility guarantees are lost, from a multi threading point of view. | |
| May 4, 2016 at 6:05 | comment | added | coderodde |
Of course it has. However, aiding debugging toString - in my opinion - should return all the stuff in one line of text.
|
|
| May 4, 2016 at 5:56 | comment | added | h.j.k. | You seem to have made an interesting distinction between human-readable output and a debugging aid... so debugging aids don't have to be readable by humans? :) | |
| May 3, 2016 at 21:39 | comment | added | Levent Divilioglu | Thanks for toString() comment, I agree but why not use final keyword? If I used this code in a big project with a team, I would prefer anyone to ask himself/herself that why a final keyword is used so that he/she could foresee that it's used for the sake of object state consistency. I also wonder that if is there any trade-off for using and not using final keyword. | |
| May 3, 2016 at 15:59 | history | answered | coderodde | CC BY-SA 3.0 |