OO Design & public vs private
Author
Please pardon as I have just read a recent related thread of public vs private, but this is more of a different question.
It is the question of directly accessing and manipulating base object variables that are public, or keeping them private and making changes or getting values only through public member functions. Using the latter for this purpose seems a bit odd to me, although I understand the reasons for it more or less. And in several ways does keep some things less cluttered. But then again, direct isnt abstract. Its right there and I can immediately see whats being done.
But my question is whether or not for all practical purposes both methods perform the same... or does using the extra functions for simple things like setting/getting variables or similar things increase overhead visibly?
cheers
One thing it is important to note here that if you are calling an accessor, that simply returns the member or a pointer to it, then you must make it inline. This is suggestive to the compiler that rather actually jump to a function call here to do one line of code, place the code in the function at the point of the call.
The compiler most likely optimises out the call thus reducing delay. So no, there wouldn't be a significant delay making the accessor call all the time as long as you inline it. Although the inline keyword probably isnt necessary where the optimisation is so obvious.
ace
The compiler most likely optimises out the call thus reducing delay. So no, there wouldn't be a significant delay making the accessor call all the time as long as you inline it. Although the inline keyword probably isnt necessary where the optimisation is so obvious.
ace
Author
One would hope the compiler would do such a thing. But better not to rely on such things I have been told.
One thing that has been a bit interesting to figure out is doing this with structs with say 4-5 floats inside. I guess you could call it a "back to the book" exercise. Creating temp struct. Placing a copying into that. Modifying it. Then passing the whole thing back will work. But to do it with pointers... ahhhh the book... tomorrow (its late) ;o)
This is my thought... and I think it sorta sounds right. Make the temp pointer. Pass a reference to it as an argument. Then assign the location of the struct to what the reference points to.
That sounds like horrible English ;o)
One thing that has been a bit interesting to figure out is doing this with structs with say 4-5 floats inside. I guess you could call it a "back to the book" exercise. Creating temp struct. Placing a copying into that. Modifying it. Then passing the whole thing back will work. But to do it with pointers... ahhhh the book... tomorrow (its late) ;o)
This is my thought... and I think it sorta sounds right. Make the temp pointer. Pass a reference to it as an argument. Then assign the location of the struct to what the reference points to.
That sounds like horrible English ;o)
The answer to your question is: Yes, there is some overhead. The overhead is generally negligible, but it ultimately depends on usage.
The overhead can be reduced to 0 if the compiler can optimize it away. There are things you can do to help the compiler optimize, such as making the functions inline.
The overhead can be reduced to 0 if the compiler can optimize it away. There are things you can do to help the compiler optimize, such as making the functions inline.
One thing I've changed as I've grown more comfortable and experienced with C++ is changing how I designed classes.
The standard tutorial always shows how to design classes about what a class is. In my experience, this makes for bad, inflexible design. Often because beginner programmers need to know what the class is to decide what to do with it. C++ does not easily allow such type information to be used.
For this thread, that means that classes are often designed around their data. Take some data that should go together, and make a class out of it. Then you get into the getter/setter tedium, and some inflexible design. After all, even with the functions, the class still -must- provide the data, since that is what the class does.
In my experience, it is by far better to design around what the class provides. In a few cases, a class provides simply data. An example is a class which contains DirectX vertex information, or perhaps an IP header. More often though, the class needs to provide functionality, or some abstract information.
With abstract information, abstracting the data from what's being provided is essential. It's not so much providing getters/setters as it is translating the implimentation of the information into what the class is designed to provide.
With a class providing functionality, the data is only there to handle that functionality. The programmer should generally not have access to it, and merely use or manipulate the provided functionality.
While either method should provide the same performance, it's rather missing the point. Making the data directly accessable either by function or by direct access is usually a design which will in essense 'perform worse' than most. With speedy computers and intelligent compilers these days, the only way you're going to make your performance suck is by using a bad design, not by wasting a few cycles here and there.
The standard tutorial always shows how to design classes about what a class is. In my experience, this makes for bad, inflexible design. Often because beginner programmers need to know what the class is to decide what to do with it. C++ does not easily allow such type information to be used.
For this thread, that means that classes are often designed around their data. Take some data that should go together, and make a class out of it. Then you get into the getter/setter tedium, and some inflexible design. After all, even with the functions, the class still -must- provide the data, since that is what the class does.
In my experience, it is by far better to design around what the class provides. In a few cases, a class provides simply data. An example is a class which contains DirectX vertex information, or perhaps an IP header. More often though, the class needs to provide functionality, or some abstract information.
With abstract information, abstracting the data from what's being provided is essential. It's not so much providing getters/setters as it is translating the implimentation of the information into what the class is designed to provide.
With a class providing functionality, the data is only there to handle that functionality. The programmer should generally not have access to it, and merely use or manipulate the provided functionality.
While either method should provide the same performance, it's rather missing the point. Making the data directly accessable either by function or by direct access is usually a design which will in essense 'perform worse' than most. With speedy computers and intelligent compilers these days, the only way you're going to make your performance suck is by using a bad design, not by wasting a few cycles here and there.
Quote:Original post by Telastyn
More often though, the class needs to provide functionality, or some abstract information.
If it isn't immediately obvious during design phases, one way to detect the problem is to look for commonality in the calling code; it generally should be moved into the class.
// badclass d00d { int health; public: d00d : health(100) {} void setHealth(int h) { health = h; } int getHealth() { return h; }}d00d d;d.setHealth(d.getHealth() - 10);if (d.getHealth() < 0) { d.getHealth() = 0; gameOver();}// goodclass d00d { int health; public: d00d : health(100) {} bool isKilledBy(int damage) { // Logically the object should do calculations, since it is the thing // with the best access to the data that is calculated with! health -= damage; if (health < 0) { health = 0; } return health == 0; }}d00d d;// And see how much more intuitive and "readable" the calling code can// be made, with a good function name choice:if d.isKilledBy(10) gameOver();
Author
Yes all these gets and sets are becoming a bit tedious. Although it does help with some of the more complex ones.
As it is, the majority of functions are already in the base class so those are not a problem. Where needed I use virtual functions in the derived classes. But those that are not require a bit more thought.
All good programming exercises.
As it is, the majority of functions are already in the base class so those are not a problem. Where needed I use virtual functions in the derived classes. But those that are not require a bit more thought.
All good programming exercises.
I would think you would only need a set function if there is a special way you want the data set (eg. you want to make sure the data is within a certain amount or whatever). Otherwise, if you function is just:
void Set( int num ) { m_num = num; }
then it might as well be public.
void Set( int num ) { m_num = num; }
then it might as well be public.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
