Re:Data Classes for Java
by arthur_pryor on Thursday November 02, 2017 @02:42PM
(#15613088)
> My argument is that having getters and setters exposes your implementation. If you have "getFoo" and "setFoo" it exposes that your class contains a value called Foo. My argument is that you should either give your methods better names, or get rid of the pretense of encapsulation altogether and just make them public. Get/Set is just an awkward middle ground.
this phrasing/perspective definitely brings me around more to your point.
My argument is that having getters and setters exposes your implementation. If you have "getFoo" and "setFoo" it exposes that your class contains a value called Foo. My argument is that you should either give your methods better names, or get rid of the pretense of encapsulation altogether and just make them public. Get/Set is just an awkward middle ground.
Even if we keep this immutable, your implementation is different in that it uses twice as much memory.
How can my implementation be different? No one else has written one (:
But maybe not. If you had getters and setters, you could seamlessly try the other implementation without changing all of the client code.
And if you had actual methods with names that didn't break encapsulation, you could do the same and divorce all your calling code from the burden of knowing about the internal structure. Again, the middling approach is the worst of both worlds to me.