class question
I have a question.Do we have to always have one extra member function in the body of the class to conect that function to the private data of the class.
|
|
Sometimes you don't want the users of the class to be able to modify a member variable directly. In that situation you create a private member and do not expose it with a matching "get" or "set" function/method.
There is nothing strictly wrong with making a variable public, but it seems to be the norm to have matching "get" and "set" functions. Some benefits of using set/get methods are that you as your classes become more complicated, you can do any required bookkeeping within these get/set functions that would not be possible if it were just a public variable. For example, having a radius variable of a Circle class be public isn't strictly a bad thing, but if you later want to attach that Circle class to an actual visual circle, creating a SetRadius function will allow you to more easily add code to update the picture of the Circle as well.
When you're just starting out coding, a lot of "good practices" seem odd and unnecessary. One thing to keep in mind is that a lot of these good practices are based on code maintenance. When it comes time to add to your code months or years later it's best to have done it right the first time. Furthermore if someone else has to understand and modify your code, it's good to have certain common practices in place.
There is nothing strictly wrong with making a variable public, but it seems to be the norm to have matching "get" and "set" functions. Some benefits of using set/get methods are that you as your classes become more complicated, you can do any required bookkeeping within these get/set functions that would not be possible if it were just a public variable. For example, having a radius variable of a Circle class be public isn't strictly a bad thing, but if you later want to attach that Circle class to an actual visual circle, creating a SetRadius function will allow you to more easily add code to update the picture of the Circle as well.
When you're just starting out coding, a lot of "good practices" seem odd and unnecessary. One thing to keep in mind is that a lot of these good practices are based on code maintenance. When it comes time to add to your code months or years later it's best to have done it right the first time. Furthermore if someone else has to understand and modify your code, it's good to have certain common practices in place.
Aren't get/set functions just public functions through which you set/get variables which are public? The thing jeffbmartinez just said, jayt. In your example there's set function. Public function that sets values of variables which are in private section of class. Sorry, if I'm wrong, I'm just a beginner... :)
well, to use your code as an example of set get functions:
class CRectangle {
int x, y;
public:
void set_values (int,int);
int get_X() const; // "get" or accessor function
int get_Y() const; // "get" or accessor function
int area () {return (x*y);}
};
void CRectangle::set_values (int a, int b) {
x = a;
y = b;
} // This is actually a "set" or mutator function but oftentimes there is a "set" function for
// each private data member.
int CRectangle::get_X() const {
return x;
} // The "get" or accessor functions return the private data member when called.
int CRectangle::get_Y() const {
return y;
} // "get" function for y
As jeffb says above, it is a good practice, when there must be access to private members of a class to the client code, to include public accessor(get) and mutator(set) functions. This insures that there is a formal contract between the client and class, i.e. the client only effects the class data members when explicitly written to do so through those functions.
Hope this cleared some stuff up. Good luck.
class CRectangle {
int x, y;
public:
void set_values (int,int);
int get_X() const; // "get" or accessor function
int get_Y() const; // "get" or accessor function
int area () {return (x*y);}
};
void CRectangle::set_values (int a, int b) {
x = a;
y = b;
} // This is actually a "set" or mutator function but oftentimes there is a "set" function for
// each private data member.
int CRectangle::get_X() const {
return x;
} // The "get" or accessor functions return the private data member when called.
int CRectangle::get_Y() const {
return y;
} // "get" function for y
As jeffb says above, it is a good practice, when there must be access to private members of a class to the client code, to include public accessor(get) and mutator(set) functions. This insures that there is a formal contract between the client and class, i.e. the client only effects the class data members when explicitly written to do so through those functions.
Hope this cleared some stuff up. Good luck.
I have mixed feelings about this subject.
Making get/set functions for everything is a little silly, IMO. For example, if making a generic point, rectangle, or some other kind of simple compound type class, making get/set members is a total waste -- it simply isn't practical. You should be able to decide what basic properties can be made public, and which should be accessed through get/set members in the planning stages.
It comes down to what you want you want the class to represent, and how you want it to represent it. Having member variables be public isn't "bad" as long as it works with the design. If you want your class to just store a chunk of data and have some supporting calculation functions (like the above CRectangle class), then I'd say make everything public. But if you want to have it bound to some other kind of drawing object like jeffbmartinez's example, then yeah you'd probably want get/set members (although then it no longer represents a simple circle -- and in that case you're probably better off making a different class for the binding)
EDIT - for a different example of why get/set functions are nice:
I'm currently working on a series of sound output classes. I have a
1) I wanted to prevent setting the volume to some illegal value (like a negative number).
2) Changing the volume level would need to stop any kind of fading effect I have going on
3) Audio mixing is done in a separate thread, so the actual change to the volume variable needs to be blocked with a mutex
Therefore simply making the volume member public wouldn't have worked.
Making get/set functions for everything is a little silly, IMO. For example, if making a generic point, rectangle, or some other kind of simple compound type class, making get/set members is a total waste -- it simply isn't practical. You should be able to decide what basic properties can be made public, and which should be accessed through get/set members in the planning stages.
It comes down to what you want you want the class to represent, and how you want it to represent it. Having member variables be public isn't "bad" as long as it works with the design. If you want your class to just store a chunk of data and have some supporting calculation functions (like the above CRectangle class), then I'd say make everything public. But if you want to have it bound to some other kind of drawing object like jeffbmartinez's example, then yeah you'd probably want get/set members (although then it no longer represents a simple circle -- and in that case you're probably better off making a different class for the binding)
EDIT - for a different example of why get/set functions are nice:
I'm currently working on a series of sound output classes. I have a
Sound class which has member vars controlling the volume and pan settings of the sound. Now I could have made these public, so that to change the volume you would just do: mysound.vol = 1.5;. However I decided not to do this because:1) I wanted to prevent setting the volume to some illegal value (like a negative number).
2) Changing the volume level would need to stop any kind of fading effect I have going on
3) Audio mixing is done in a separate thread, so the actual change to the volume variable needs to be blocked with a mutex
Therefore simply making the volume member public wouldn't have worked.
Last edited on
I agree. Object-oriented programming is about data encapsulation and hiding. A class that contains a data member X should own it. Making a public mutator (setter) for it means that everyone owns it, because everyone seems to know what value it should hold. Now, there are exceptions to this rule; Disch's example is a good example of a case where it makes sense to provide a setter.
If you find yourself needing to write getters and/or setters for all or most of your data members, you are not doing object-oriented programming; it is more like structured analysis using the keyword "class" in C++ rather than "struct" in C.
If you find yourself needing to write getters and/or setters for all or most of your data members, you are not doing object-oriented programming; it is more like structured analysis using the keyword "class" in C++ rather than "struct" in C.
Topic archived. No new replies allowed.