Is defining get/set methods for every field overkill?

On Saturday, 19 November 2022 at 19:59:20 UTC, Ali Çehreli wrote:
> ..
> ...
> Ali

The 10 years was mentioned, because it was what I learnt over 
that period (well, long before that actually). It wasn't 
mentioned to demonstrate that I have some superior knowledge. 
Object data needs to be protected. It often needs its 
'invariants' altered.

There are far more reasons for inserting getters/setters and 
design stage, than leaving them out at design stage, in order to 
save some keystrokes, or code bloat.

How often do you design your class? How often to users use your 
class, and ask for changes? Better to anticipate change - the 
cost of that is much smaller  at design time.

If you learnt something different over your 30+ years, good for 
you, and your team, and your customers.

But in my experience, public member variables rarely make sense 
in a 'class' type, and I'd put protected in the same principle.

This is not a hard and fast rule. But it makes sense in most 
cases.

Perhaps you can direct me to a software engineering *team* that 
builds *class* library's for a living, and that also use public 
member variables in their classes. Perhaps they can teach me 
something I do not know. I'm happy to learn more.

Your post was mainly about struct types?? This thread is about 
the relevance of getters/setters in a 'class' type.

btw. If you can get away with using public member variables, you 
likely don't need a class type.