|
|
|
|
|
by elegantlie
490 days 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. |
|
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?