3 ms·
Avoiding temporal coupling is always a win. Bonus points for avoiding mutable state in classes entirely. It’s certainly not always possible, and requires a shi
by donatj 6y ago
Avoiding temporal coupling is always a win.
Bonus points for avoiding mutable state in classes entirely. It’s certainly not always possible, and requires a shift in mindset, but we’ve been trying to actively avoid state not set by the constructor and it’s had a very positive affect on our codes readability and reusability.
- hibbelig 6y agoIf you can't mutate, then all parameters need to be passed to the constructor. With the builder pattern, there is only one call of the constructor. But I still find it to be a pain if there are a lot of parameters. Maybe with named method parameters, it's better, but Java does not have those. Of course, lots of parameters are a code smell, I know. But what do I do? We have a business logic entity that always needs a creator (a user), a current owner (another user), the user who last modified it, a creation timestamp, a last modification timestamp, and a couple of other things. (And that's before we get to the actual data that's stored in the entity.)