Printable View
Hey all,
I am searching the whole web for a good class getter and setter function tutorial but i cant seem to find any, i have lots of books but none of them talks about that...
Can anyone help me find a book or a site that gives a good explanation on getter and setter function for classes.
Thanks in advanced.
There isn't really much to it. Start by considering a non-class situation, a simple C approach using a global variable:
That's the basic idea. Now let's say the data is a more complex type - an std::string, say. In that case, you should pass a const reference to the set function, and return a copy from the get function. And keep in mind that when dealing with classes, it's customary to declare the get function const, since the object isn't being changed in the process. If you don't, of course, you won't be able to call the function on a const object, or if the object has been passed as a const reference to a function.Code:int
data = 0;
void set_data( int value )
{
data = value;
}
int get_data( void )
{
return data;
}
Good. They are usually a sign of a poor design, so you should avoid them.Quote:
Originally Posted by MasterM
>> Good. They are usually a sign of a poor design, so you should avoid them.
Not necessarily. It gives you better control (eg: you can filter or reject changes), and it allows the internal implementation to change without breaking existing code. It also make the interface more uniform, since you don't have to access data in the class in different ways. Personally, I prefer to use the same name for the get/set pair, but I know a lot of people don't like to do this, due to possible ambiguities.
It's also a good idea to set your getter function as constant to make sure that it doesn't accidentally get changed by the rest of your program.
I don't think he was proposing exposing member variables. Pure design says that a class should only expose operations. Getters and setters expose state, not operations.Quote:
Originally Posted by Sebastiani
In my opinion, the real world doesn't work that way - getters are very often unavoidable, and even setters are needed from time to time.
>> I don't think he was proposing exposing member variables. Pure design says that a class should only expose operations. Getters and setters expose state, not operations.
Well, to be sure, he wasn't clear on that. Even so, to say that get/set functions are a sign of a poor design because they expose state is a moot point. All functions essentially get or set the state of something. But I do agree that "functions that expose unnecessary state information" should be avoided.
If you find doing something like
then perhaps the class is not exposing operations as it should. (Also, if state is complicated, providing lots of setters can make it hard to validate everywhere that conditions are met.)Code:if (move_left) {
enemy.set_x(enemy.get_x() + 1);
}
Another thing is naming:
Would these members qualify as getter and setter?Code:class Enemy {
bool alive;
...
bool is_alive() const { return alive; }
void kill() { alive = false; }
};
>> then perhaps the class is not exposing *operations* as it should.
Maybe, but I still don't see what the point is in making a distinction between *state* and *operations*. The terms are interchangeable, IMO.
>> Another thing is naming: Would these members qualify as getter and setter?
Why not? Personally, I would name the member variable 'alive_' and the get/set pair 'alive'. Accessing them then is a lot more like dealing with properties. Works for me, anyway. :)
In general, classes should model behavior, structs should model data. Unfortunately, we see a lot of beginners who think classes are simply promoted structs with the appropriate getters and setters. So instead of ...Quote:
Originally Posted by Sebastiani
... we see ...Code:class Car {
public:
void drive();
};
Code:class Car {
public:
void setSteeringWheel (SteeringWheel sw);
SteeringWheel getSteeringWheel();
void setSparkPlug(SparkPlug sp);
SparkPlug getSparkPlug();
...
};
>> Unfortunately, we see a lot of beginners who think classes are simply promoted structs with the appropriate getters and setters.
It doesn't really have anything to do with get/set functions (specifically), though. That is, *any* and *all* superfulous functions should be avoided.
>> In general, classes should model behavior, structs should model data.
Seems like an arbitrary distinction to me, anyway.
And what if you want to change the implementation:Quote:
Why not? Personally, I would name the member variable 'alive_' and the get/set pair 'alive'. Accessing them then is a lot more like dealing with properties. Works for me, anyway.
My code had kill() but prevented resurrecting an enemy (well, one can always create another enemy).Code:class Enemy
{
int health;
....
bool alive() const { return health > 0; }
void alive(bool a)
{
if (!a) {
health = 0;
}
else {
????
}
}
}
It's easier to control what can and cannot be done with a class if you keep the number of setters low.
>> My code had kill() but prevented resurrecting an enemy (well, one can always create another enemy).
OK, well, I hadn't thought that one through much. :p