Accessor functions

I've been wondering. I've seen a lot of classes that have private variables, and then have public functions for accessing them. My question is... why?

Surley it would be faster to set the variables directly. It would also be easier to code, as well as lowering the space needed by the class. The only reason I can think of for using accessor functions is so that I can check some values arent out of bounds, like setting a width of a window to a number less than 0. But if the whole program is being written by myself and people on my team, then what does it matter? Surley I can make EVERYTHING in the class public, since I'm the only one that will change it anyway. So why would I want to use accessor functions for variables in my own classes?

One of the key advantages of C++ is encapsulation, the ability to restrict data access to specific functions. Sure you can make everything public, but you'll be taking a backwards step.

Remember the three key features of C++:
- Encapsulation
- Inheritance
- Polymorphism
They're all there to make your programming life easier, use them.

Yes I know I should use encapsulation, and I normally do, and I also use polymorphism and inheritance. I was just wondering WHY I should use encapsulation. I can understand why people making libraries used by other people like an XML parsing class would want to use encapsulation, but for a class only used by myself surely its not neccessary?

>>for a class only used by myself surely its not neccessary
>>why should I...
because it's good practice ;) Besides, if you don't want the features of class, use a struct.

Hehe, "Because I said so" (no offence meant, I am grateful for your answer, but its not what I was looking for). I think "Good practice" doesn't warrant adding about 50 accessor functions to a class that can have up to 100 instances of it at once, always being deleted and created. Nor does it warrant re-writing many MANY lines of code.

I can't use a struct because I use polymorphism and inheritance, and I also have other member functions that a struct cannot have. Thanks for the help though hammer :)

>>about 50 accessor functions
Hmm, sounds like rather a lot of methods. Maybe your design could do with rethinking (just a thought).

>>100 instances of it at once, always being deleted and created.
If you're worried about memory allocation problems, create an array of objects at once (either static allocation or dynamic), then use an accessor class to get them. This way allocation only occurs once. You'd have to create a method to replicate a destructor that doesn't actually free the memory, only clears the data elements.

Not that I disagree with the gist of Hammers arguments, but, just to make it clear, structs in C++ are different than structs in C. In C++ the only difference between a struct and a class is that members are public by default in structs and private by default in classes. You CAN have functions in structs, nest other structs/classes in structs, use inheritence, polymorphism, whatever in structs with C++, just like you can with classes.

One reason that encapsulation is good practice, I believe, is that it makes it easier to make changes to your class later without affecting all the code that uses it.

I experienced a good example of this recently. I had a class that was not written by me that had 5-6 boolean members and 4-5 other enumerated members that had 3-4 possible values each. In the implementation of the class, most of the time accessor methods were used to access those members. The accessor methods were of the simple inline return data; variety.

In an attempt to decrease the memory usage of the library, I decided to combine all of these properties (the bools and the enumerated members) into a single ULONG so that each option only required a single bit. I then changed the accessor methods to do the appropiate bit manipulation to set or return the value.

Because the rest of the code used the accessor methods, I didn't have to change the 10,000 lines that used those properties. I'd say the time it took to write the accessor methods in the first place was probably a lot smaller than the time it would have taken for me to change all the code when I did my optimization.

Anyway, that's just an example of how it could help. Even if you don't have a situation like that, I'd still consider following good C++ programming techniques, just because. And if you don't, I doubt it will be the end of the world.

Quote:

---

Surley it would be faster to set the variables directly.

---

Then use inline accessors.

Quote:

---

It would also be easier to code,

---

Not really to my mind but it's a matter of taste.

Quote:

---

as well as lowering the space needed by the class.

---

If you use inline stuffs, it does not increase the size of the exe.

Well, what could I say? If you do only code for yourself, you can do whatever you wish. However, you're going to be in troubles if you want others to read/help you with that code.

jlou has already given an example. By making your data members public you're exposing the implementation to the client, rather than just the interface. If you then wish to change the underlying implementation - which is not uncommon - you break client code that uses it.

You've also touched on another reason, validity checking the value of the data member when it's set.

By making your data members private and enforcing the use of accessor functions to read/write to them you're controlling access to the data members. You're permitting them to be changed only in certain ways, through the accessor functions. If you make them public anyone can change them at any time whether you like it or not.

The overhead of providing accessor functions is rarely an issue.

Just thought I'd throw in my 2c...

When I'm designing my program and classes, I like to make variables and the like private when I'd like a global variable for a class, but don't want the rest of the program to have access to it, or I want to restrict it's value range (like you say).

It's fine making everything public, but when you come back to the same program some 6 months after you have been working on several other projects, you loose track of what you were doing and what everything did, so have to rely on comments. Forcing variables into public/private sections and using accessor functions for modifying suddenly makes your life a LOT easier, as what you did back in the design stage just saved you a lot of time debugging because you've accidentally used a variable that was not supposed to be modified, or was modified incorrectly.

Secondly, I always decide what variables are public/private and what there accessor functions are in the design stage and proove that the methods actually work on paper before writing a single line of code. This again may seem strange at first, but reduces bug fixing by an huge amount and means that you have all the workings out for when you come back to the program 6 months later and wonder why you did a certain thing in a such a way.