Open velizartodorov opened 3 years ago
So basically I need to use builder whenever the class implementation is subject to change? Does this include classes that are not part of the public API? If I am sure that class will stay as is forever a normal constr will do? Here I have used all-args-constr in the builder since all the fields are required. If requirements need more fields - setters can be easily added for those.
So basically I need to use builder whenever the class implementation is subject to change? Does this include classes that are not part of the public API?
Builder
pattern is used, when a composite object needs to be built (having multiple properties). Compare these two examples:
Category(String property1, String property2, String property3, String property4, String property5, String property6, String property7, String property8)
category.builder()
.property1(smth)
.property2(smth)
.property3(smth)
...
build();
Which is easier to read? Imagine the following madness as well:
Category("String1", null "String2", null, null, "String3")
etc.
Builder prevents this nightmare of null params.
Both for API and internal use it's a good practice, since you and your teammates will be also consumer of your own code.
If I am sure that class will stay as is forever a normal constr will do?
Yep, but being sure about that it's hardly never the case. :)
Here I have used all-args-constr in the builder since all the fields are required. If requirements need more fields - setters can be easily added for those.
I'd use all-args-constr if the properties are no more than 3, as Bob Martin suggests. If I have to set all fields at once, setting through Builder pattern is a better approach. If the states of the object require different properties at different places in the project itself, I'd go for the setters approach only.
https://github.com/nanovche/expense-tracker/blob/62d3f2e5dc3c7f51fe5f968d5518da08cef777ae/expense-tracker-api/src/main/java/com/pairlearning/expensetracker/domain/Category.java#L11
For now, you have a few properties in this class and adding them through the constructor is not a problem. But imagine if the client requirements change, and you have 20 - your constructor will become an absolute nightmare to instantiate and initialize. Use
Builder
pattern instead. Same thing goes forTransaction
andUser
classes.