Well ok I see your point. A getter and a setter would be irrelevant extra
verbage at this point.
Nevertheless if it were me I would make the value a const.
The point of protecting the variable at all is to prevent anyone from
changing it (accidently or maliciously) and instead making sure that they
have to explcitly change it. In my mind a variable that must be read, but
not altered is the definition of a constant.
This is not intended to start a flame war on Java vs C/C++ ways of doing
things.
Consider for a moment the hypothetical bit of code.
if(pStart->nVersion = 2){do something new}else{do the old thing}
if nVersion was defined as a constant, then this would throw a compile
error the first time you built it. But with the current code the "do
something new" block would ALWAYS run, and the "do the old thing" block
would NEVER run. Thus, you might never know there was a problem until
existing clients started breaking.
Obviously the problem here is that the programmer accidently assigned 2 to
nVersion instead of comparing it for equality.
(Be honest, we've all had this happen more often than we care to admit).
Now consider, what would happen if in a later revision we wanted to change
nVersion to a string for internal accounting purposes for instance
"2.1.1"? As a const or var we would have to go back through and change all
references to it so that all subsequent actions are ready for a string
type. With a getter method we only need to make sure we have a getter that
returns an int and nothing else would break (assuming this had been done in
the beginning, or a 1 time change if done later on). That's the power of
encapsulation.
Nothing wrong with the pythonic way of doing things, but in this case I
believe we are just talking about OO best practices i.e. loose coupling
achieved by strong encapsulation. That would be true in any OO language.
On Wed, Jan 22, 2014 at 7:58 PM, Michael Torrie <torr...@gmail.com> wrote:
> On 01/22/2014 07:38 PM, S. Dale Morrey wrote:
> > Also yes ->nVersion is a pointer to the int nVersion contained in pStart,
> > there are no other shiny bits involved.
> > Honestly if I were coding this from scratch I would have made nVersion
> > private and added a method getVersion(); That's probably my Java
> > experience talking, but it seems like better OO practice in my mind.
>
> But if we're talking about a public, versioned, protocol, that's defined
> in the header file, then there's really no need to add a getter and
> setter, since the underlying implementation is never going to change.
> Sounds to me like you are dealing with what is essentially a
> well-defined protocol (publicly defined in the .h file), though it's
> probably not versioned. And the code you posted doesn't say it is a
> class, either. It could just as easy be a struct, as is common.
>
> I know there's money to be made in Java, but things like getters and
> setters make me want to run screaming from it. Right back to
> comfortable, flexible, expressive, and slow Python.
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
