Re: public member variable vs. get/set functions
On 12/9/2013 5:39 PM, W Karas wrote:
The main purpose of private members is to provide some level of
compile time checking for the rules of use of an object that must be
followed, in order to keep the object in a valid state.
<shrug> I probably wouldn't call it "main purpose", but we can take it
as an assumption.
Given that, a private member variable with (simple, public) get/set
functions just seems like pointless code bloat. It provides no
additional protection against putting the object in a bad state than
having the member variable be public.
"Simple"? You mean, "obvious" or "apparent"? Well, perhaps. You can
call it a "placeholder", though, and then it's not necessarily so simple
anymore. Later you can decide to make it more complex, add validation
(if that's what you're after), and then it's not *at all* the same as
having a public member.
Some (perhaps Smalltalk fans) argue that it's very rare that simply
setting a member variable should properly be part of an objects
public interface. Therefore, it's best to follow the rule of thumb
that all member variables should be private.
It can also be argued that it is often important, for code
maintenance, to be able to quickly identify external changes to a
member variable, as opposed to read access to the variable. A
counter-argument is that some sort of code browsing tool should be
available to prevent the need to bloat the code in order to highlight
this distinction.
If those getter/setter functions are "simple", as you call them, then
the "code bloat" is not significant, and from the code maintenance POV
it's better to have a function that gets inlined by the compiler than
have the name of the member data strewn around the rest of the user
code, which also carries the danger of pointer or reference retention
and can cause other kinds of trouble.
In some cases, it could be likely that the get/set function would
eventually do more than simple get/set a single member variable.
That would be a clear case where keeping the member variable private
would be the correct choice. But, as I have seen Dr. Bjarne argue,
it's easy to go overboard with future-safety.
Your thoughts?
It's easy to go overboard with anything one does. Still, a little
planning ahead goes usually a long way. If you think you need to ask
the "why do it if we don't need it" question, then don't forget to ask
the "what's it going to cost to add it later if we do need it" as well.
V
--
I do not respond to top-posted replies, please don't ask