|If my thinking is wrong, or if this is grossly inefficient, I’d very much like to know why. It’s why I created the thread in the first place. I’d also like a clear explanation of why it’s wrong rather than outright condemnation of the practice.|
Encapsulation is the defining characteristic of OOP. If every member has a getter and setter, the class is not encapsulated. Without encapsulation, there is little reason to use classes.
Encapsulation is difficult to explain without falling back to examples. But the general idea is you want your class to represent a "thing". The class is in charge of maintaining its own internal state. The code using the class does not need to know (nor should it know) how the class works internally. It only needs to know how to use the class.
This allows for many long-term advantages. Some of the biggest are these:
1) It allows the implementation of the class to be greatly reworked/revamped at a later time. As long as the public interface of the class does not change, the implementation can undergo a complete overhaul... and no code outside the class will need to be updated
If every member has a getter and setter - an overhaul / rework is much more difficult, because removing (or even renaming/repurposing) variables requires all code that gets/sets that variable to be adjusted.
2) When a bug is exposed in the behavior of a class, you know the bug is somewhere in that class. So you only need to go through 1 or maybe 2 source files to find and fix the bug.
When everything is publicly mutable with getters/setters, your member variables are effectively globally exposed, so bugs can be introduced by anywhere in the program. It makes it much harder to pinpoint exactly what code is causing the bug.
3) Hiding implementation details is necessary for polymorphism. If you expose implementation details, code that uses the class is relying on those details. If you want to swap that class out for a similar (sibling) class later, you might not be able to because the implementation details will likely be different.
|For example, I frequently want to get a program running as quickly as possible to fulfill some need.|
You sound like you are doing procedural programming. There's absolutely nothing wrong with that. I just assumed since you were talking about classes and private members in your original post that you were interested in OOP.
The problem with OOP is that it's not fast. Or at least... designing the classes is not fast. Effectively designing classes takes quite a bit more planning and foresight than your typical "code as you go" procedural program. The tradeoff is that properly designed classes are more stable, easier to use, easier to reuse, easier to expand, and easier to maintain.
So if you just want to quickly throw together something that does a small job -- you probably don't need (or want) OOP. OOP is strongest in larger projects where you're more interested in scalable, long-term functionality rather than getting a skeleton program out quickly.