It also makes it harder down the road when you add new functions to the object and have to change the 23523423562346 places you call the constructor on that object.
This is a non-issue; either the new data is required before the object can be used and you would have to change those places anyways, or it’s not required and it can be an optional parameter of the constructor.
This is not ideal IMO.
Well, neither is create-set-call. Everything has trade-offs.
I think the real question is whether there are language features or other approaches that can capture the advantages of both styles.
In languages that don’t allow optional parameters, I think that the builder
pattern is a nicer api than straight-up create-set-call, because it means
that you can validate the parameters at the build step, before someone
tries to do something dangerous with a half-constructed object.
[Comment removed by author]
This is a non-issue; either the new data is required before the object can be used and you would have to change those places anyways, or it’s not required and it can be an optional parameter of the constructor.
Well, neither is create-set-call. Everything has trade-offs.
I think the real question is whether there are language features or other approaches that can capture the advantages of both styles.
[Comment removed by author]
That’s Richard’s point #2: the tradeoffs of different styles are very dependent on language features.
In languages that don’t allow optional parameters, I think that the builder pattern is a nicer api than straight-up create-set-call, because it means that you can validate the parameters at the build step, before someone tries to do something dangerous with a half-constructed object.