Encapsulation. When used correctly it makes programs easier to debug and also easier to check for correctness. Plus it lets you treat your class instances as conceptual objects.

OO activists will give you answers like "it promotes encapsulation", "it allows for higher level programming", etc. The real reason is so that the idiot in the office next to you doesn''t futz with your code in a way he or she shouldn''t. When you start working with large code bases and teams of 10+ programmers it''s easy for even the people whom you consider "smart" to do stupid things.

The point of using member functions to get at the data, instead of accessing it directly, is less to keep people from messing with your data, and more to keep it accessed in a consistent way.

For instance, if you say MyClass.GetElement(index), it doesn''t matter whether the underlying structure is an array, linked list, or something totally bizarre. You can even change the underlying structure type at will without breaking ANY other code.

It might seem redundant at first, but it helps keep your code more organized, self-comments in many ways (more obvious what you are doing when you call a logically named member) and will just generally makes changing stuff easier.

Hope that helps.

STOP!

This topic has been discussed twice in the last week already. PLEASE use the search facility to at least look back over the past month in a given forum for the subject you want. In these days of worrying about GameDev bandwidth usage, posting duplicate and/or redundant threads is a Bad Move.

Here:

This thread starts out "I was kind of wondering what the advantages of private members are" and is exactly the same thing you''re asking.

This thread mainly talks about why people sometimes make a variable private and then access it with public functions.

Check those threads, and then post again if you need to ask about specific points.

Greetings.

Imagine you had some sort of graphical object, and one of its data members was an integer holding what frame of animation it was on.

When you are writing this object it seems like you will need to just increment this integer once in a while, and that is it. You make the object a public member.

So you write say 5000 lines of graphics code and all is well.
When you need to you increment your object''s integer.

Soon you find that you need to do something to, say, optimise a specific video card''s memory or load a triangle mesh or check the proximity to another graphical object or check to see if some surfaces are still in memory etc etc etc, every single time you increment it.

You incremented it say 100 times. You could write a script to change the code, or use search and replace which isn''t much fun to do if you change/add to that code around a lot, etc.

You could just implement the change globally in some public member function, a function perhaps called IncrementAnimation(), it would be extremly easy to do so, and it has other benifits than just fixing what is broken faster.

If you had been using that manipulation function all along, it would be no big deal, you could do other things when the frame of animation incremented just by changing the definition of incrementation.

Imagine this, some other people use this code. Maybe 1 other person uses it, maybe a whole team use it, maybe more.

Since they can access your data member publically, they will probably use it incorrectly, possibly making your object or other code into a plie of digital junk. If you had made it a piece of private data, then it would be impossible to do, your object would be useful to them because they would use it in the correct fasion.

Your objects may only be used by yourself, but even then you will increase their reuseablity by a great amount if you make data objects private, and have public or protected member functions to manipulate them.

I think that data encapsulation is a difficult topic and you may have to write many programs before you come to realize its use and its usefullness. It extends naturally from functions, which you are familiar with.

I am new to posting on message boards. It often seems that a critque is seen as an insult of some sort, I do not insult you. Maybe you indeed are a craphead and deserve it, maybe you are a saint, more likely you are neither. That said I have one such a critque for you, I am sure you have more than one for me, as I am not a great writer, please listen to mine...

Suggestion:
If you don''t understand something please do not call it stupid. Neither you or it are stupid. Perhaps you could ask for an explanation of where such a thing would be usefull to you, or of why it exists.
Do not limit this to computer science. It applies elsewhere.

Thank you.

Bye.

Well, it''s mostly to force you to write modular code. If there''s a faster way to access the element... why not write that method into the accessor function and make it inline? Then it will always be that fast. The optimizer should do a good job with that.

Even doing it differently once can cause problems down the line, through cutting and pasting (so it becomes more than once). Or if you happen to be working on a team, by other people adopting that as the standard method for accessing the member.

And if you still think you really, really need to access the member directly in just one place, make that one place a friend class. That still forces encapsulation everywhere else.

The rule usually is, if you think you need to access data directly, then the block of code that needs to access it should probably be a member function of the class you''re trying to access.

That said, for really simple data you can, and often should, use a struct instead of a class. It''s exactly the same as a class, but is public by default rather than private. This makes it easier to shoot yourself in the foot, but I write games for a living, and I know fast-quick-n-dirty is often the best way to do it.

In general, make your game''s main systems (graphics system, sound system, game AI, game rendering, main game loop, etc.) into well defined classes, hiding most of the icky details behind private sections (even create private member functions to hide functions that should only be called locally). At the next level down (data inside each class) you can be a little more relaxed, since local data (that is private) can be accessed locally.

In the end, it''s all about making things clear in your own mind (and anyone else who needs to look at the code). Sometimes a struct IS clearer, but at a high level it opens the door to bugs and hard to maintain code.

quote:Original post by ironfroggy
I do understand the usefullness of encapsulation. Believe me, I do. But still, why not keep everything public?

2 contradictory sentences.

quote:Remember the rule, 90% of the time is spent in 10% of the code. Best have that 10% as quick as possible.

Then keep the other 90% private.

I think I''ll just keep on posting this link: http://www.cuj.com/experts/1902/hyslop.htm?topic=experts