> Oh, and for good measure--everytime you force yourself to use an accessor, you are providing the opportunity for somebody down the line to add debug and validation code.
So add it then. Don't pre-generalize everything just in case.
So add it then. Don't pre-generalize everything just in case.
This isn't premature abstraction or architecture astronautics--this is just good practice.
If you are in a language like Java or C, your compiler should optimize away the call if it doesn't do something clever.
If you are in Ruby, this is so easy to do that it doesn't even need mentioning--you just call the variable directly and behind the scenes you have replaced the variable name to be a function doing your magic instead.
If your fingers protest at the additional "get" in your function names, go and buy yourself a real IDE.
EDIT: Parent thread added clarification worth noting here. I'm not saying you should add accessors for every protected member--that's just as bad. I mean to say you should only expose members that absolutely require it (the fewer the better, generally), and only do so through function interfaces you can hook. :)
This actually isn't as wildly hypothetical a situation as one might guess. At least in the Android world, "Avoid getters and setters" is on the short list of performance suggestions.
http://developer.android.com/guide/practices/design/performa...
Even if the (Java, or otherwise) IDE can generate piles of crap code, I still hate reading piles of crap code, though. Sometimes I just want a "struct" :-)
Now back to my Java work...
Plus, no, often I can't afford a function invokation. Because it's yet another cache miss.
If all of those things don't matter (or you work on a large enough team that the benefits of abstraction are worth it), yes, add getters/setters everywhere. For the rest of us, we might have actual _reasons_ why we don't cargo-cult our code.
If you can't see how abstraction layers affect performance, go buy yourself a real education. This isn't about premature optimization, it's about not applying premature generalization.
Sometimes it immediately makes sense to add accessors. In that case I add them right away.
Sometimes there is no apparent need for accessors, so I don't add them yet. They're easy to add (you argue so vehemently yourself), why would there be a problem adding them as needed?
A blanket rule of "just add them, always" is just a crutch for mediocre developers who aren't capable or willing to actively think about what they're working on.
Conventional wisdom is there for a reason--it was wisdom hard fought over many iterations from people who came before. Conventional wisdom has won out against many competing ideas, a survival of the fittest of sorts. You may not always fully comprehend the reasoning for a particular 'best-practices' rule, but you're foolish not to follow it for that reason.
Adding accessors is not 'premature generalization', it's just how you write well engineered code.
On a more serious note, trivial accessors generally don't result in any more compiled code than direct field accesses, but do have the advantage of abstraction. If your development process is limited by the time it takes you type out the name of an accessor (or in my case, the first 3 letters), then you must be really productive or not do other things like documentation or testing.