3 ms·

Sure, for a simple class like this I would make it immutable too. But the example is just a demonstration of the concept - you should be able to change the imp

Sure, for a simple class like this I would make it immutable too. But the example is just a demonstration of the concept - you should be able to change the implementation without changing the exposed interface. When you first write a class, it may look like a simple bag of fields. But when that inevitably changes, getters and setters allow you to do it without breaking the clients. Even if we keep this immutable, your implementation is different in that it uses twice as much memory. Maybe it's irrelevant, or maybe it's worth the tradeoff to use more memory and have faster access to the kelvin representation. But maybe not. If you had getters and setters, you could seamlessly try the other implementation without changing all of the client code.

HumanDrivenDev 9y ago
But the example is just a demonstration of the concept - you should be able to change the implementation without changing the exposed interface. 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.
- arthur_pryor 9y ago
  > 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.

HumanDrivenDev 9y ago

But the example is just a demonstration of the concept - you should be able to change the implementation without changing the exposed interface. 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.

arthur_pryor 9y ago
> 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.