3 ms·
They enable your option 2 and allow the implementation to change behind the public API. Should theta/R have getters is entirely up to your API decisions. The
by jayd16 2y ago
They enable your option 2 and allow the implementation to change behind the public API. Should theta/R have getters is entirely up to your API decisions.
The point of getters and setters is they're the bare minimum of encapsulation. The advice is to ensure even reading a field should be abstracted so implementation details do not cause large reactors of downstream code.
How this is conflated with 'every field should have getters and setters' like it is in this discussion I do not know but that is not the intention.
- geophile 2y ago> Should theta/R have getters is entirely up to your API decisions But it often isn't. The blog post starts out talking about how that field -> getter/setter pattern is very widespread, and tools (JavaBeans tools for example), make that pattern unavoidable sometimes. Yes, it should be an API decision, but for a variety of reasons -- tools, patterns, coding standards, cargo cult programming -- it isn't.
- jayd16 2y agoWhat's the point of this article if those are unavoidable and unaddressed?
- ethbr1 2y agoOO design is ultimately API design. Unfortunately, it's often taught with toy noun examples that have obvious/actual internal fields and data structures. It'd be better taught solely using abstract nouns, to better nudge learners into explicitly thinking about external/API design vs internal state. Or, in other words, getters and setters are subcases where the external/API exposed is 1:1 with internal state.