I\'m a total newbie with tons of ?\'s in my mind and a lot to experience with C++ yet! There\'s been something which I find really confusing and it\'s the use of public vari
I cannot agree with this opinion that public members are evil. C++ is not C#. I would always avoid things that I don't really need when coding in C++. Using public members is completely fine if
Despite what some people say, I believe accessing public variable leads to a cleaner code than using some function calls to do practically the same. This of course depends on what kind of project it is and how will the class be used and how it might be used in the future. Writing getters and setter just in case is in my humble opinion useless.
As a reference, read C++ guidelines (C.131)
Getters and setters are indeed a good practice in most cases. But the fact is that your current example is too simple, and therefore is not a good candidate for defending private members access through get/set().
One of the more interesting trends is auto implemented properties. So instead of having to write the getters and setters you just have to write a property and the compiler does the rest. You still have the option of writing the getters and setters, but you don't have to write all of the boiler plate code for what should just be 1 line. If you need to add range checking etc later, you can just create the property the old fashioned way and keep the interface to your class the same.
I have seen this in the latest versions of C#, Objective-C and VB and it can be quite helpful. VB's implementation doesn't offer as much flexibility as C#, but I am sure it will catch up pretty quickly.
These are called "getters" and "setters." One good reason to use them is that you can add extra code later without changing the interface. In your example it doesn't look like they do much, but in more complex classes they're practically essential.
OK, As I understand, your question is this: Why make a variable private and then make two functions which just retrieve the value and set the value without any checks? If there were checks, you'd understand, wouldn't you? For example, if you set the hour field of a Time class, checking that hour <= 24
is a good idea.
But when no checks are applied the idea is this: if at some point you decide to change the setting and getting functions, for example, perform some checks in them, the whole code that has been using your class need not be recompiled
Also, the general purpose of encapsulation is that one communicate with the class only via its interface, without knowing how it is implemented. The more inner info you hide, the better.
When do you use public variables? When you make objects that have no behavior. Ones that are just a conglomerate of data. For example, see std::pair
. A pair is just a struct, with public first
and second
.
In general, one cannot give a strict criteria when to use which way, but you'll feel it yourself with gain of experience.
HTh
One argument runs something like this:
If code external to the class in question relies directly on a particular member, making a change to that member means changing every piece of code that accesses it. If instead it is accessed by member functions, you can keep that part of the interface the same, and only have to make changes to that class to keep external code working.
Using "getters" and "setters" gives you some flexibility built into the coupling of your objects.