"to**********@v ol.at" <to**********@s tudents.fh-vorarlberg.ac.a t> wrote in
message news:11******** **************@ i39g2000cwa.goo glegroups.com.. .
Hi!
My prof told me always to make my members private or protected cause
its standard to write setter and getter methodes.. Is that in your
opinion correct? Cause I dont see any adventages to write a member of a
class private if there are no side effects in changing the variable. I
think you only have to write more (the getter and setters) the code
gets bigger...
Thanks very much!
First of all, let me say that a good old fashioned C struct is OK by me. I
use them myself for working with legacy code and writing C-compatible
interfaces. They aren't objects but they are perfectly valid data
structures. However, for the rest of this message let's assume you are
interested in using C++ for object oriented programming.
The real objective of object oriented programming is maintainability . It is
hoped that by separating the interface from the implementation one can
modify the interface without breaking any client code. This is the reason
(not "side effects") which makes public data items a bad, or at least
non-object-oriented, idea. By the way, in spite of you professor's comment,
protected data members are no better and for the same reasons.
Your professor is probably right that it is "standard" to access each data
member with a get/set pair, but it is an abhorrent convention. Such
interfaces focus attention on the implementation. The function of the
interface is to HIDE the implementation! Get/set pairs completely destroy
the illusion that the object is anything more than what Stroustrop calls a
"bucket of bits". You seem mystified by why they are so much better than
public data. I am with you.
You may think that object oriented dogma aside, as a practical matter it is
often necessary to use get/set pairs. Believe it or not, I write a lot of
C++ objects for my work and I literally NEVER use get/set pairs. Of course I
would if I found a practical reason why they were required, but so far it
hasn't come up. For instance:
class complex
{
public:
complex(double re, double im);
double re() const;
double im() const;
private:
...
};
Although I would never write my own complex type with such a good one
available in the standard library, I assert that this is a perfectly usable
object interface with no performance issues and, as you can see, no get/set
pairs.
Cy