Printable View
Bit of a trivial question here, but anyway.
I've decided to order my class functions alphabetically, so I can find what I need quicker.
The problem is, I have a ton of get/set functions for private variables. My question is, by convention, should I order 'em in Get/Set pairs (eg. getEast, setEast, getWest, setWest) or chunk all the Gets together and all the Sets together? (eg, getEast, getWest, setEast, setWest)?
--Ashiq
I'd put the get/set pairs together, personally.
Does the ordering in the declaration or definition affect the way it will run, or is it just an aesthetic thing?
You may also consider having them fall in the order in which your internals are declared:
I also like pairs. It's really just personal preference. You should pick one method and try to stick to it, so that your classes have a common form.Code:class Foo
{
public:
int getBar( );
void setBar( int s );
char getC( );
void setC( char tothis );
...and so on...
private:
int bar;
char c;
...and so on...
};
The key is to pick a style and stick with it.
[edit] To answer the above question, it's purely for looks and ease of readability. [/edit]
Quzah.
Sounds about right to me. Thankee!
--Ashiq
As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.
If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.
In this example why is value even private? Value might be private, but it can be accessed like a public member and though this does not illustrate what I'm trying to say in full, it might give you an idea of what my point is. No point in making a member private if you are going to create multiple public functions that override the protection mechanism. Kind of coding in circles.Code:class Foo
{
int value;
public:
Foo(void) {value=0;};
void Set(int tvalue=0) {value=tvalue;};
int Get(void) {return value;};
};
So if you have a get and set for every private member in your class, I would tend towards the notion that you are simply using those functions to override the inherent protection mechanisms in C++.
Just a thought.
A better way is to derive one or more classes from one or more base classes. This way, the private and protected mechanisms would be used correctly. Private is used for a member that is needed by the current class and no one else. So if another class needs to have access to that member, consider making it protected and derive another class from it. For more information on classes and what the different keywords do check a book on C++ or your help file.
I disagree somewhat with the way you say we should do public functions. Maybe if they're ALL using set/gets, that would be kind of...crap. But using set functions in particular ensures that you don't accidentally change the value of your variable somewhere. I did that in a program once, took me 3 days to track it down. I can see the reasoning behind set/get functions...
--Ashiq
Quote:
If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.
I agree that this low level of direct access is not typically desirable, but there are significant advantages to use a get/set pair over a public variable.Quote:
Originally posted by Bubba
As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.
1) Separates interface from implementation -- the calling code doesn't need to know how the variable is internally stored, and the internal storage mechanism could change without breaking client code. For example, perhaps the variable for west is actually part of an array of integers.
One of the "laws" of good OOP is that a published interface is set in stone. Putting implementation details as part of that interface is a bad idea -- it locks you into one kind of implementation only, because you now can't change how you implement that particular variable without defining a new interface.
2) Permits validation of the data. SetYYYY() can make sure the value being given to it is within the range of valid options. Even if you don't do this at first, it's good to have the option to do this later.
Overall, I can't think of a good reason to EVER use a public variable except in a struct-like class, where you're not really encapsulating, just grouping data together. You should always use Get/Set pairs and a private variable instead.
Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.
This:
did not imply:Quote:
As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.
but it did imply:Quote:
Overall, I can't think of a good reason to EVER use a public variable except in a struct-like class, where you're not really encapsulating, just grouping data together. You should always use Get/Set pairs and a private variable instead.
because again:Quote:
Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.
So real quick:Quote:
If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.
- Public variables= bad idea
- Private variables=good idea
- Public functions used to continually thwart privacy=bad idea
So
if
public variables==bad idea
and
private variables with several public functions which operate on said private variable - thus really treating it like a public variable==bad idea
then
time to redesign the class.
Sums up my thoughts quite well.Quote:
Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.