public and private variables
What is the difference speed wise in declaring a variable or function in a class public or private? I tend to make most variables public on the chance I may need them. How does if affect performance of the program?
Thanks!
Thanks!
Recommended :
Of course if you make all public it will damage the virtue of OOP Object - Oriented... that a class is not secured anymore.
| Variable -> Private Function -> Public Helping Function -> Private Mutator and Accessor Functions Included. |
Of course if you make all public it will damage the virtue of OOP Object - Oriented... that a class is not secured anymore.
^ *Rolls eyes*
Oh yes, let's make all our variables private, and write public accessors for them. Let's write lots and lots of code doing nearly nothing at all! That sounds like waaay more fun than solving an actual problem!
Oh yes, let's make all our variables private, and write public accessors for them. Let's write lots and lots of code doing nearly nothing at all! That sounds like waaay more fun than solving an actual problem!
Just wait until you need to put some constraint on one of your public values.
Have fun going through hundreds or thousands of lines of code and fixing your code that accesses those variables directly.
Have fun going through hundreds or thousands of lines of code and fixing your code that accesses those variables directly.
Or you could actually DESIGN things ahead of time.
Or C++ could have attributes (things that look like members but are in fact accessors).
Or C++ could have attributes (things that look like members but are in fact accessors).
C++ does support them, you just have to work for it by making sort of 'proxy' objects that have an operator= that takes the type of the object and has an operator object_type() to convert it to the object. These can then be public member variables that will allow safe getting and setting. This emulates C#'s attributes, in a way, but isn't perfect. it works the way you want it to in most cases though.
What I'm getting is it only helps you organize your code later; it doesn't really effect performance. Is that right?
Function overhead affects performance, but you will save yourself many, many headaches by using getters and setters. Directly accessing the variables means that whenever you want to impose a limitation on them yo have to go back through all your code and fix things. Not fun, or easy to track down.
getters are and setters is likely to be inlined so there shouldn't be any performance difference at all.
At runtime? Probably no difference.
At compile time? A small difference.
At writing time? A big difference.
At compile time? A small difference.
At writing time? A big difference.
Yes, at writing time using getters and setters will save you a LOT of hassle, and in the end save lots of time.
Last edited on
dad, why can't I change the size of vector?
|
|
Last edited on
How could the std::vector know to delete elements that no longer exist and/or initialize new elements? That's why there is a resize function that handles it for you.
Were you being sarcastic?
Last edited on
Only if you're doing something like XP where you don't design anything. The time spent writing getters and setters (that is the same code over and over) could better be spent actually thinking about what members' getters and setters you'll need, and which would be better done by defining a data type with the restrictions you want. Getters and setters are the antithesis of DRY.
Last edited on
What happens when you need to impose a new restriction on something you never wrote a getter/setter for? You'd probably be wasting more time in the long run. Plus, getters and setters only take a few seconds each to make, whereas tracking down direct-member-access code and fixing it can take hours.
Last edited on
Just because you have a data member doesn't mean you need to create a setter or getter for that data member. I think that the number of getters and setters should be kept low. If all you do is pass around a bunch of data I think it is OK to put them in a class as public.
Functions can be good for hiding implementation details. If the internal implementation changes the interface can stay the same. The vector has a size() function to get the size and a resize function to set the size. Inside the vector there might be a data member for holding the size but it doesn't have to be. We don't need to know.
Functions can be good for hiding implementation details. If the internal implementation changes the interface can stay the same. The vector has a size() function to get the size and a resize function to set the size. Inside the vector there might be a data member for holding the size but it doesn't have to be. We don't need to know.
I agree mostly, for simple data structs used internally of course I never write getters or setters (they're internal!), but anything that I expect may be used by someone besides me who does not know the correct way to deal with things, I design getters and setters for.
Yes, those acessors and mutators should be kept low. And it's a good practice to do it this way.
I put all my data in private.
If your class has a large number of getter and setter functions than it means it is just a bunch of unrelated stuff offering no functionality to the class user (i.e. bad design)
If your class has a large number of getter and setter functions than it means it is just a bunch of unrelated stuff offering no functionality to the class user (i.e. bad design)
Topic archived. No new replies allowed.