There are infinite possible futures but only one now.
Write the best possible code needed today. Anything else is premature abstraction.
I do get the "what if" temptation, I just think it should be actively resisted.
See [YAGNI](http://wiki.c2.com/?YouArentGonnaNeedIt).
A helpful (to me) metaphor is that you're paying for an option. (In the finance sense, not the type system sense.) Sometimes it's worth buying an option, sometimes it's not, but don't think it's free.
A more simple analogy: it's an insurance.
It's certainly wise to subscribe an insurance for your house, but for every single drinking glass you own...?
If it's a tea set you inherited from your great-grand-mother, when you break it the insurance won't un-break it. If your property suddenly needs to be more than a property, chances are that this change will break the LSP or trigger a larger redesign anyway.
Re:Porting 4.5K lines of C to Go
by MrBuddyCasino on Saturday August 05, 2017 @04:51AM
(#14934842)
This not one of those instances though. The cost of having getters/setters is essentially zero, the potential downside can be big.
Ok, reality time: out of all the getters/setters you've ever written, how many of them have you ever needed to modify? And for those modifications, how long would it have been to refactor your code base to go from public field access to publi method access ?
Six months later, you discover that you, in fact, do need to do something besides getting/setting the value.
If you created a getter/setter, you could just change its code. If you, instead, had raw access to the field, you now need to update every single instance of client code that called your getter/setter.
Most of the time, your compiler/VM can optimize the getter/setter call away, and a bunch of trivial get/set logic isn't exactly the worst source of cognitive overhead.