Timeline for Why would a type be coupled with its builder?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:40 | history | edited | CommunityBot | replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/ | |
| Mar 16, 2017 at 15:46 | history | edited | CommunityBot | replaced http://meta.codereview.stackexchange.com/ with https://codereview.meta.stackexchange.com/ | |
| May 5, 2016 at 11:27 | comment | added | chrylis -cautiouslyoptimistic- | @Luaan Odd. I've literally never seen it used and didn't know it existed; toString() is universal. | |
| May 5, 2016 at 11:22 | comment | added | Luaan | @chrylis .NET doesn't have a string constructor that takes a StringBuilder argument. You have to take it in context with Mat's comment before :D | |
| May 5, 2016 at 11:14 | comment | added | chrylis -cautiouslyoptimistic- | @Luaan It's unclear what exactly about .NET's approach you prefer, since the Java API is identical there. | |
| May 5, 2016 at 7:47 | comment | added | Luaan | @Mat'sMug StringBuilder is a performance optimization of a mutable string, it's not a builder of the String type (not the least because there's nothing to build on a string - ignoring implementation complexities, string is just "one value"). Just because something is called XXXBuilder doesn't mean it implements the Builder pattern for type XXX. That said, I still like .NET's approach better - StringBuilder.ToString() gives you the string "built" by the StringBuilder (in .NET, the two are exactly the same, except that string is immutable; it's just a runtime hack, really). | |
| May 5, 2016 at 5:55 | comment | added | chrylis -cautiouslyoptimistic- | In Java, for the case you describe, it would typically be more idiomatic to have a Person.Builder and perhaps a private constructor on Person. | |
| May 5, 2016 at 0:48 | vote | accept | Mathieu Guindon | ||
| May 4, 2016 at 23:11 | comment | added | enderland | I'm pretty sure that in real life, several Persons can build other Persons. Is this like builder-ception? | |
| May 4, 2016 at 21:30 | history | edited | Jeff Bowman | CC BY-SA 3.0 | Reword "upon" to "on" and make some small formatting changes. Also note that the Builder can be consumed from a different construction utility. |
| May 4, 2016 at 19:07 | comment | added | Jeff Bowman | @Mat'sMug Within the package, either String consumes StringBuilder, StringBuilder consumes String, or they're colocated in the same top-level class. Outside the package, it doesn't really matter; they're both integral parts of the same API surface. And, for a lot of relevant commentary, see this API design talk by Josh Bloch where he explains his advice and (like in Effective Java 2nd Edition) he critiques the bad API design choices in the Java libraries. Link goes to 36:41, but the whole talk is worth watching. | |
| May 4, 2016 at 18:40 | comment | added | Mathieu Guindon | Fair enough. I still don't get the String(StringBuilder) constructor though, which seems to obey to that "principle" where it's normal for a type to have a dependency on its builder. I was flabbergasted when I saw that constructor overload. It's not like a String has 42 constructor parameters... | |
| May 4, 2016 at 18:34 | comment | added | Jeff Bowman | @Mat'sMug My post above takes it as a given that the class needs that many constructor arguments. I'd likewise treat it as a design smell if we were talking about an arbitrary business logic component, but for a data object, it's not of the question for a type to have ten or twenty direct attributes. It's no violation of SRP for an object to represent a single strongly-typed record in a log, for instance. | |
| May 4, 2016 at 18:22 | comment | added | Mathieu Guindon | Yet, I can't seem to shake off the idea that a type with too many constructor arguments is a design issue (smells of breaking SRP), that a builder pattern swiftly shoves under a carpet. | |
| May 4, 2016 at 18:11 | comment | added | Mathieu Guindon | I think I see your point about treating the constructor as an implementation detail. It just doesn't seem like Effective Java properly conveys this message then (I don't have / didn't read that book), leaving a ton of junior (?) Java devs assuming "that's how it's done" regardless of common sense. I agree that the Wikipedia examples are bad for comparison.. but hey it's Wikipedia.. and FWIW I don't actually care for the downvote; the deleted answer is sitting with a positive net score anyway (and there goes my chance to finally score a [badge:peer-pressure]). | |
| May 4, 2016 at 18:02 | history | edited | Jeff Bowman | CC BY-SA 3.0 | Add note about the mutable Car example, and extend the benefits regarding constructor control to include serializability or validity. |
| May 4, 2016 at 17:37 | history | answered | Jeff Bowman | CC BY-SA 3.0 |