3 ms·
I’ve written a lot of C# and have heard the proclaimed reasons. I’ve stopped doing this over time. You almost never need the interface and when you do, I haven’
by tyleo 2y ago
I’ve written a lot of C# and have heard the proclaimed reasons. I’ve stopped doing this over time. You almost never need the interface and when you do, I haven’t found it hard to add.
Maybe you do this by default if you are developing an external API for versioning reasons but that’s such a niche use case.
- lostmsu 2y agoWhen you change from fields to properties with getters and setters you break binary compatibility with previous versions, which is very bad for libraries.
- blincoln 2y agoHow much legacy code have you maintained/added features to vs. writing new code? I find that getters and setters seem like pointless overhead when I have an idea that I want to test empirically as soon as possible, but if I don't, I end up with a lot of regret years later when I have to track down all the references and update them instead of just changing code in the one place. I'm not a fan of lazy loading, but I know a lot of people are, and using the getter/setter pattern also enables fairly straightforward ways to lazy-load properties from persistent storage (or add that capability down the road if it becomes advantageous).