Printable View
I was just wondering what's the point in using them, maybe there is something about private data handling out of the application that I am not aware of, though. Anyway, I don't see what's the point of having something like this:
So why having an accessor, I think it goes against the encapsulation rule, but anyway my teacher says we should do so... What is good to do... and to know?Code:class x
{
private:
int a;
public:
int Access_A(void)
{
return a;
}
};
I really despise these teachers that tell you to do something just because. I had them in my time too.
Acessors actually don't go against encapsulation rules. They are part of what keeps that rule alive. What you do on that code (although calling it Access_A() makes me shiver :) ) is making sure a is not changed anywhere in the code except there. Or... to be more precise looking at your code, a is not read by any other means than with that function.
Remember that encapsulation is not meant to hide information. It's not a mechanism to hide code. It is "simply" a mechanism to separate the interface from the implementation. A user of your class X doesn't need to know about the variable a, how it is declared, how it works. It just needs to know that he has a function called Access_A() that allows him to change the state of his object of type X.
Consider the class std::string. You have a function called clear() which removes all elements from the string. You, as the user don't care how it does it. You just need to know it does it. That's crudely what encapsulation is. Making your data members private and providing them when necessary with read and write accessors is one way.
Of course, if your whole class is made up of private data members and public acessors whcih can read and write them, you have a pretty boring class (however it can still be useful and there is nothing stopping you from designing this type of classes. Also classes are not boring. They are either useful or not). But despite all those accessors you are still enforcing encapsulation. You are still separating the interface from the implementation.
In that case, Access_A provides read-only access to a, so users of the class can't change the value of a when they shouldn't be.
In other classes, there is a get and a set method, in which case the question is a little more valid. However, even when you provide a get and a set method for your private variable, you are still encapsulating that variable and allowing yourself the ability to change the class implementation in the future without affecting all the code that uses that class. You are also allowing yourself to add side effect code to occur when that variable is changed.
One example is a string class. Most implementations will contain a private member variable holding the size of the string. They also provide member functions to get the size and to set a new size (e.g. size() and resize()). If they made the size variable public instead of providing those accessors, then they wouldn't be able to catch when the user makes the size bigger and they need to allocate more space.
Ok thanks, I understand more now...
:) I agree to this!Quote:
I really despise these teachers that tell you to do something just because. I had them in my time too.
>> I agree to this!
I don't. Why waste time covering less significant details when there is more to be learned. If you really want to know why, or you just don't believe the teacher, then ask the question just like you did, and you will get good information in return. Although I do agree if the teacher has the time but still refuses to go in to deeper explanation or direct you to other resources for explanation.
Note also that std::string for example lets you access the length of the string ::size(), but it won't let you change it. (To be more exact, change it in a way that string::size() does not reflect the actual length of the string.)
So, if the user needs to see some value, you can provide a getter. But if it is unwanted that they be able to change this value, you can not provide a setter.
If the value is only used by the class itself internally and the user doesn't need to know anything about it, you needn't provide a getter nor setter.
You probably didn't consider that if the teacher had actually explained about encapsulation, mikahell wouldn't be questioning about that code. I think encapsulation is an important concept the teacher should explain.
I did, and I addressed it. I think it is good that the question was asked. And I don't necessarily mind that the teacher didn't explain the entire concept at this point. Perhaps if I was teaching I would have gone in to more detail than this particular teacher did, but my point is that in general, it is not always bad to say "just because" instead of explaining every detail of every issue.