Question about Classes and their Member Variables

[ApexCin777]

I am reading a book title "Sam's Teach Yourself C++ in 21 Days" and it's real good. But now I'm stuck on a section and need help.
It says that it is a rule of thumb to declare Member variables of a class as private and declare the Member function public. Then you can access the variables by making the functions public accessors.
It says this way is better than just making the variables public.

I understand how to do this but I don't understand why it is better. The book tells you why it is better but I still don't understand. Maybe you can help me by reading what the book says below. THANKS to anyone who can help!

From the Book:

Accessor functions enable you to separate the details of how the data is stored from how it is used. This enables you to change how the data is stored without having to rewrite functions that use the data.

If a function that needs to know a variable's value accesses that variable directly, that function would need to be rewritten if you was to change how that variable in that class was stored.
(I don't understand why you would need to rewrite it...EXAMPLE PLEASE!)By having the function call a public accessor of the class, the class can easily return the right value no matter how you arrive at the variable's value. The calling function doesn't need to know whether you are storing it as an unsigned integer or a long, or whether you are computing it as needed.

Back to me:

I think what it means by 'the way the variable was stored' is it's data type like integer or double. I'm not sure. I just need an example of why it is better. Is it like symbolic constants are better than literal constants because you can change it once and it changes all? Please help?

[NigelQ]

Your logic is fine. Indeed you could expose the member variables as public and have everyone access it as they need.

The reason it's better to use functions to access private member variables is to maintain a better, more modular, or isolated approach to object oriented design. Do you really want external classes or routines to change your class' internal variables whenever they feel like it (without your knowledge) ?

By using these routines, you can very easily add protection to the class if the need arises.

You could for example check to see if the external caller (whoever it is) is passing a valid value into your variable, and you could also add thread synchronization easily if access to the variable is encapsulated in a couple of routines.

Better yet, if access to the variable is made like this to begin with, everyone outside the class will always access the variable in the same way, whether these tests and synchronization mechanisms are in place or not - they are blissfully unaware of any apparent changes in their access.

You may also need to take some additional action within the class should the value of the variable ever change.

These same arguments hold true not only for variables within a class, but also the methods of a class - why make anything in a class anything other than public...

Hope this helps,

- Nigel

[jfaust]

This example is simple and contrived, but it may drive the point home. Imagine a class that has a piece of data called m_title, which is a string title for that class.

First, imagine that this is public and everybody set the title by simply accessing the variable: myObject.m_title = "Hi Mom!".

Scenario 1: The program has evolved over the years and contains several hundred thousand lines of code. There is a bug in the software having to do with this title being set incorrectly at some point. Since this title is set in hundreds of places, it may be very difficult to track down. If this was set through a method (SetTitle()), it would be much easier.

Scenerio 2: The program again evolves and everybody and his brother is setting the title directly. Now you want the title to show up in the window, not merely saved internally. This is not a small task--you need to change every call. Again, if everything went through SetTitle(), it would be almost trivial. You see, it allows you to change the behavior of the class without changing the public interface to it.

There are other reasons such as thread safety when using multiple threads, and other reasons I can't think of right now.

One more thing--there are better books available. The best I've seen is written by Deitel and Deitel. It's set up as a textbook, by chapters, but is also an excellent reference once your an expert.

Good question! Have fun,

Jeff