Printable View
The way I see it is you can do everything classes do in structs and quicker. For Example:
Code://class
class object
{
private:
int number;
public:
void setnumber(int set) {number=set;};
int getnumber() {return number;};
};
int main()
{
object test;
test.setnumber(12);
cout<<test.getnumber();
}
Thanks.Code://struct
struct object
{
int number;
};
int main()
{
object test;
test.number=12;
cout<<test.number;
}
Because most people use classes for more than just grouping a bunch of variables together.
Missed the point about public/private members?Quote:
Originally Posted by yaya
Also because C++ focuses on OOP, classes are an important part of it. Not making everything public, and accsessable to every function is known as good practice. But then again, C programmers will argue that they do use OOP techniques when they code. It is purly done by choice, but the main point is to use a struct when you have small amount of grouped data and a class when you have a large amount, thus needing to be more carful over which part of the program you give the acsess to.
Oh, I see. Thankyou, and sorry if it seemed like an ultra-stupid question.
Get/Set for every member is not really necessary, though. If I need such a thing, then I just make the thing public.
The better choice is to make a real class with OOP focus instead of just a data struct...
Making the variable public though kills the entire point of accessors (and thus to a small degree OOP) - making it easier to change how a chunk of data is handled by just changing one method and thus also aiding debugging. Even if I will never change how the data is handled, just potentially reducing the time I spend debugging makes it more than worth it.Quote:
Originally Posted by Elysia
Yes, making all variables public is a bad idea.
But there's really no point in just adding members, making them private, and then implementing get/set for them. If you're going to do that, you might just as well make them public.
But if they have another purpose, then it's a good idea to have them remain protected or private.
But what if you have an int member which only has a valid range of 1 to 100?Quote:
Originally Posted by Elysia
If you make it public, anyone can set it to an invalid number, but with a Set function, you can return an error if they try to set it to something bad...
Also, for multi-threaded applications, Get/Set functions allow you to lock that piece of code while the value is being changed. You can also add some extra logging for debugging purposes...
Then you are using that variable for something specific, so you shouldn't make it public. In that case, you would probably want to make the class emulate the behavior of an int, as well, eliminating the need for get/set.Quote:
Originally Posted by cpjust
Good points.Quote:
Also, for multi-threaded applications, Get/Set functions allow you to lock that piece of code while the value is being changed. You can also add some extra logging for debugging purposes...
But then again, I haven't had the need for that (although it doesn't mean someone else won't).
So anyway... if you think it's worth it, then sure, there's nothing wrong with it. But generally, I find it to be more typing/overhead/functions that necessary.
Yes there is. It adds encapsulation, and allows you to later change how they are implemented.Quote:
Originally Posted by Elysia
For example let say you have a circle object. And you need to get it's area. You could have the circle calculate it's area each time it is needed. Or you could decide it is better for optimization reasons to just add an extra area member. Having an accessor method hides this choice from the code using the method. This allows the programmer to switch between the two choices without changing the API and code using the object.
That seems like you're just programming for today, rather than the tomorrow. When version 2.0 of your program is in development and all of the sudden the requirements change a lot, you'll be glad you spent the extra time adding data encapsulation, especially if your program is a core component in several other programs, since you probably need to maintain API compatibility for those other programs...Quote:
Originally Posted by Elysia
But, all of this is as I mentioned, that it uses that member for something. If the variable is used for anything--anything at all, then you should consider making it private instead. But if all you do is use it as a struct, then I don't see the point.
You're right cpjust, in that I haven't had the need to worry for such things. What you mention does make sense, and might be a good idea. It actually shines new light upon the situation.
But it depends much on the need.
I think I'm going to have to ponder on that one and its usability within my own environment.