Jump to content
  • Advertisement
Sign in to follow this  
helix

Protected vs Private

This topic is 4846 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Q: Is there ANY reason to use private instead of protected (besides the obvious hiding of members from derived classes)? Specifically, is there a performance hit? A couple coworkers were looking at some of my code a few months ago and asked why I made the member vars in a class protected instead of private since it wasn't being extended. I thought it was a stupid question at the time. But I just had to change one of their classes to be protected since I'm now extending it so I feel a little vindicated. I know that using virtual functions adds a small performance hit due to the usage of the v-table but I am under the impression that protected vs private is almost exactly the same thing and whether you inherit from it or not, there is no reason to use private (in most cases). This has been standard practice for me ever since my first c++ class in college years ago.

Share this post


Link to post
Share on other sites
Advertisement
There is no performance difference between private and protected. Access retrictions are applied at compile time, not runtime.

That being said, I would avoid protected data. Protected member functions are ok, but protected member variables tend to have long term code maintenance problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
There is no performance difference between private and protected. Access retrictions are applied at compile time, not runtime.

That being said, I would avoid protected data. Protected member functions are ok, but protected member variables tend to have long term code maintenance problems.

why?
they work preety much like private variables right?
so what would be the complication?

Share this post


Link to post
Share on other sites
That's pretty much what I figured. But why would there be a maintainence issue with it? Maybe that's what my coworkers were getting at. I still think that unless there is a real reason why something should not be visible to it's derived relatives, it should be protected.

Share this post


Link to post
Share on other sites
Well, if you make variables protected rather than private, it can introduce maintenance issues if derived classes use those variables, since derived classes are now dependent on those variables.

If you choose to change the functionality, such that those variables are no longer needed, say for example you want to split that functionality off into a seperate class, you will have to change every derived class that uses those variables.

A better way to do it, is to have protected methods that access the private variables. That way, derived classes are not reliant on the protected variables.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oxyacetylene
... That way, derived classes are not reliant on the protected variables.


So now they'll be dependent on protected member functions? I must be dense... but huh? How is that better?

Share this post


Link to post
Share on other sites
It's better for the same reason that public functions are better than public variables. You can change the definition of the function without directly affecting entities dependent on that function.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oxyacetylene
If you choose to change the functionality, such that those variables are no longer needed, say for example you want to split that functionality off into a seperate class, you will have to change every derived class that uses those variables.


That makes sense...but I think it is acceptable. I'd rather do that than use the functions suggestion. I'll just name any new variables differently if necessary.

Quote:
Original post by SiCrane
It's better for the same reason that public functions are better than public variables. You can change the definition of the function without directly affecting entities dependent on that function.


That also makes sense. I haven't found this to be a problem though. Maybe if I worked on much larger scale projects it may become an issue but so far, I'm MUCH happier with protected variables.

Share this post


Link to post
Share on other sites
I agree with SiCrane, not only can protected data members be bad mojo its abit of contradiction to what you where originally trying to do that is to provide loose coupling between unrelated types & modules, to enforce state invariants, to support liskov's substitution principle. By making data members protected you've just blown that all away by allowing clients (or yourself) to subvert that by derivation. Related sub-type should not be any different than the same privileges that unrelated types/modules have, inheritance should be about extending behaviors not implementation (theoretically speaking)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!