Jump to content
  • Advertisement
Sign in to follow this  
Raeldor

Hiding Private Members... How Far Do You Go?

This topic is 4876 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

I understand it is good practice in C++ and object oriented languages to hide private members and just access functions to change them and their data. Makes sense. Thing is... how far do you take this with game programming? For example, at the moment I have a terrain class which has textures. These textures are an array which is a member of the terrain class. I can access these textures outside of the class because the textures array member is public. If I made this member not public and have access to work with these textures provided by functions I would assume there would be overhead, but at the same time I can see the benefit from a maintenance point of view. So how far do you go? Thanks

Share this post


Link to post
Share on other sites
Advertisement
I used to just make everything public.

Now I generally make data in non-gamespecific classes [rendering, input handling, networking, algorithmic stuff] private; game object classes tend to still be all public though.

The change mainly came from me changing my design tendancies. Before I'd generally tend to write a class thinking "what does this class need?", and now it's more like "what's this class going to do?". Because of that, I tend to write a lot more interfaces [erm. pure virtual base classes for groups of possibly templated objects] for things. Non-game objects tend to deal with that nicely since they're often read-only anyways. Some game objects don't since they're not really objects but bundles of data. In that case the data is the interface, so it just tends to be public.

In the future, probably even more will get private once I learn how to do it/design it well.

Share this post


Link to post
Share on other sites
People have different ideas of what should be public. I usually have all data private and provide accessor functions. This is unless the class is "pure data", for example a Vector math class. It would just be silly to have to type v.getX()/v.setX() instead of v.x and its not likely that the internal representation of a vector is going to change in the future.

Oh, btw there is no performance overhead to using accessor functions as long as they are properly inlined.

Share this post


Link to post
Share on other sites
if other people will ever be touching the code, make everything private and provide accessors and modifiers(mutators). Remember, people code differently so someone may accidently touch one of your members. Making them private assures that this will never happen and that your data is always clean, unlike some inferred text in this post. Never let other programmers touch your private members.

Share this post


Link to post
Share on other sites
Making important variables private will ensure security. When you are working in a team, it is important that your variables are secured. The public variables can be altered without any indication. It is advisory to use private variables with function interfacing to access those variables.

Share this post


Link to post
Share on other sites
Hi,

Private methods and attributes are not just for hiding away from callers and calling implemenetations. They also encapsulate the class' own private data and prevents other inheriting class from inheriting the methods OR the attributes.

Let's say we have the following class :

class cBaseClass {
protected:
int protNumber;
private:
int privNumber;
public:
int getPrivNumber(void);
cBaseClass(void);
~cBaseClass(void);
}

and have an inheriting class

class cChildClass {
protected:
private:
int childPrivNumber;
public:
int getChildPrivNumber(void);
cChildClass(void);
~cChildClass(void);
}

here's the catch :
- cChildClass can access cBaseClass::protNumber directly, using this->protNumber and it'll still work.
- cChildClass can access cBaseClass::privNumber only by using cBaseClass's accessor method - this->getPrivNumber() [Since cChildClass IS A cBaseClass]

I usually put all my game attributes in my game classes as private. And apart from all the accessor methods, some class-specific methods are made private also so that they're not inheritable NOR overwritable.


I hope this helps ... and pls correct me if there is any mistakes :)

Share this post


Link to post
Share on other sites
you can inline your accessors and mutators so speedwise this shouldn t matter

if you really need to access you private member variables from outside the object you can still rely on friend classes

Share this post


Link to post
Share on other sites
Private, Protected, Public, Internal, Implementation, Friend, etc. etc. are not there to hide stuff but to protect you (and others) from abusing/using local (design) decisions.

Environments like Java and .NET allow you (and others) by using Reflection to get access to these private attributes and operations. So from a security point of view it doesn't do much...

In other words: don't get overexited; keep your pants on! (That will hide your private members) (sorry, couldn't resist...)

Cheers

Share this post


Link to post
Share on other sites
Hi,

Quote:
Original post by ernow
Private, Protected, Public, Internal, Implementation, Friend, etc. etc. are not there to hide stuff but to protect you (and others) from abusing/using local (design) decisions.


Not exactly. An encapsulation hides implementation details. This is the final goal of any OO language - enforce the "program to an interface" paradigm by hiding implementation details. Of course, it also protect you from abuse, but that's more a side-effect than a real goal.

Quote:
Original post by ernow
Environments like Java and .NET allow you (and others) by using Reflection to get access to these private attributes and operations. So from a security point of view it doesn't do much...

You can use "da bad stuff" in C++ to access private members:

class A
{
private:
int a, b, c, d;
char *p;
public:
// ...
};
class A_public
{
public:
int a, b, c, d;
char *p;
public:
// ...
};
A myA;
A_public *myA_public = (A_public *)(&myA);

This is obviously horrific. As horrific as using relection in Java of C#. But helas, you can't forbid this. Security can be enforced to a certain level, but if you need to deal with dumb programmers, it is of little help. The only solution - and they deserve it - is to kill them, but it's a bit extreme.

Quote:
Original post by ernow
In other words: don't get overexited; keep your pants on! (That will hide your private members) (sorry, couldn't resist...)
Cheers


Yep [wink]

Regards,

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!