Always making members private/protected?

[tobias.sturn]

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!

 

[Victor Bazarov]

My prof told me always to make my members private or protected cause
its standard to write setter and getter methodes..

That would be a wrong reason. But the advice is sound.

Is that in your
opinion correct?
Partially.

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...

I think what your prof doesn't tell you is that what members to have
is secondary to what objects of your class are supposed to look like
(and *act* like) to other objects in your program. Design not from
the class itself, but from the way it's interacting with the rest of
your model.

Once the public stuff is finalized (through design), you begin the
implemenation phase and there you decide what *else* your class will
need to provide (mostly to itself through private members, or to its
descendants through protected ones).

V

 

[Jonathan Mcdougall]

Hi!

My prof told me always to make my members private or protected cause
its standard to write setter and getter methodes..

"Never" and "Always" are seldom good advices.

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...

I think the best answer would be: it depends. The advantage of using
member functions is that you can control the access to member objects
or even completely hide them. The more you hide implementation details,
the easiest it is to change them. However, the more abstraction layers
you add, the more complex the code is. You have to make a compromise
between abstraction (genericity) and simplicity (usability).


Jonathan

 

[W Marsh]

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!

Then you need to learn about OOP, probably outside of the classroom
environment which won't prep you for any suitable real-world tasks.

Quick analogy: Would it be beneficial for the passengers of an
aircraft to interface with the cockpit instruments? What would happen
if they /did/ press the big red button marked "jettison fuel tanks"?

 

[Tomás]

(e-mail address removed) posted:

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?

I gather that he suggest you write:

class Monkey {
private:

int a;
char b;

public:

void SetA( int const arg ) { a = arg; }

int GetA() const { return a; }

void SetB( char const arg ) { b = arg; }

char GetB() const { return b; }
};


rather than simply:


class Monkey {
public:

int a;
char b;

};


This is ridiculous and amounts to overkill most of the time. But there
are places where it's prefereable to use Getters&Setters. For instance,
maybe in the future, you will rewrite your class such that you no longer
store your values in simple member variables... you might store and
retrieve them from a database for instance. If you have Getters&Setters,
then your client can be totally oblivious to the change in
implementation:

class Monkey {
public:

char GetB() const
{
global_database.open();

global_database.verify_record(17);

return global_datebase.current_record.value();
}

};


However this is extremely rare -- far too rare to adopt a strategy of
ALWAYS writing Getters & Setters. If anything, it demonstrates the
programmers lack of intelligence -- he can't think for himself because
he's too busy adhering to doctrine.

Cause I dont see any adventages to write a member of a
class private if there are no side effects in changing the variable.

And you're correct.

I think you only have to write more (the getter and setters) the code
gets bigger...

And you're correct.


I myself have never written code with Getters&Setters. I even prefer to
have "read-only" members rather than Getters on their own. For instance:

class Monkey {
string str;

public:

const string& cstr;

Monkey() : cstr(str) {}
};

Now "str" is modifiable within the class, but constant to the outside
world.


-Tomás

 

[Tomás]

Tomás posted:

class Monkey {
public:

char GetB() const
{
global_database.open();

global_database.verify_record(17);

return global_datebase.current_record.value();
}

};

Actually I still wouldn't use Getters&Setters here -- I'd prefer an inner
class which can implicitly convert to "char":

class Monkey {

class Ape {

Ape() {}

Ape(char const arg) : b(arg) {}

operator char() const
{
global_database.open();

global_database.verify_record(17);

return global_datebase.current_record.value();
}
};


public:

Ape b;

};


Or something along those lines. Functions are for algorithms -- not for
finding another way of setting a variable's value.

I never have used Getters&Setters, and it doesn't look likely that I ever
will.


-Tomás

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

My prof told me always to make my members private or protected cause
its standard to write setter and getter methodes..

No, the better way in general is to provide methods that does some action or
obtain some information, and the user of the class must not care if they
read or modify directly a member variable or not.

By the way, protected variable members are also not recommended. Read for
example the comments in "The C++ programming language" about that.

 

[Joe Van Dyk]

(e-mail address removed) posted:





I gather that he suggest you write:

class Monkey {
private:

int a;
char b;

public:

void SetA( int const arg ) { a = arg; }

int GetA() const { return a; }

void SetB( char const arg ) { b = arg; }

char GetB() const { return b; }
};


rather than simply:


class Monkey {
public:

int a;
char b;

};

Probably would want to use a struct here. More obvious.

 

[Tomás]

Joe Van Dyk posted:

Probably would want to use a struct here. More obvious.

I first wrote it using "struct", but right before I clicked "Send", I
realised that there was a chance the original poster would come back with
"What's the difference between class and struct?". For this sole example, I
found it preferable to use "class". (You can't teach someone everything at
once -- just one bit at a time).


-Tomás

 

[Cy Edmunds]

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

 

[gustelev]

I like to use smth like that:

class A
{
int var;
public:
int Var();
void Var(int);
}

 

[Luke Meyers]

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...

I think others have answered the basic question here adequately.
"Always" is a bit strong, and your prof is wrong about getters and
setters for the design reasons mentioned already by others in this
thread, but most of the time your data members should be private
(usually not protected, for the same reason they're usually not
public).

Besides saying "me too," I want to take the opportunity to mention a
piece of phrasing I came across which I feel concisely embodies one of
the most valid exceptions to this rule of thumb. I believe I came
across it in Koenig's _Ruminations on C++_. In a discussion on this
guideline, the author mentions an exception for (simple) classes for
which the structure *is* the interface. This is basically just a way
of describing the "classic C-type struct," but I find the notion of
structure as interface to be a useful and novel take on an old idea.

But yeah, apart from exceptions like that, hide 'em away. If you find
yourself wanting to write (many) getters and setters, interpret that as
pain which is a hint to reexamine and improve your design.

Luke

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

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...

If you have a getter/setter-pair for nearly all attributes of your class
and few other methods then you should probably consider making it a pure
data-container (and perhaps indicate this by using struct) with all
attributes public. If you have many attributes compared to the number of
getters/setters you should probably keep them.

Erik Wikström

 

[Ian Upright]

Actually, I think this would make sense only if it could be proven that
making the getter/setter functions inline caused the generated code to be
identical or no less performing to that of directly referencing the instance
variables. This would allow you to transition from an inline function into
a virtual function, without any additional cost.

I'm not sure if this is true or not for all compilers, so I don't really
know the answer. Perhaps others can comment on this and prove it one way or
another.

Ian