4 ms·
I never understood this argument for statically typed languages like Java. > You can add validation for all setters, and abstract it as an interface later if n
by elegantlie 2y ago
I never understood this argument for statically typed languages like Java.
> You can add validation for all setters, and abstract it as an interface later if needed.
Sure, but why not just postpone the introduction of setters until you actually need them. 90% of time you don't, in which case we just saved a ton of boilerplate and ceremony. The 10% of time that you do, converting public variables to a setter method is about 2 IDE clicks these days.
The only argument I can think of is if you are exposing a public library API, in which case you need to worry about backwards API compatibility.
- jayd16 2y agoGenerating getters is actually 2 IDE clicks that will protect you down the road. Trying to refactor fields that made it into a public API is a nightmare. If you're shipping code people use, you won't get to refactor their projects from your upstream library. Also, no one is suggesting everything needs a setter. Where is this coming from?
- alserio 2y agoIf I could I would make this two IDE clicks behind a big mean warning. In my experience people tends to autopilot it without thinking about what that entails.