Quote:Original post by Funguz
So.. I read in c++ manuals, that when creating classes, you should make the members private if you want to control "who" can access the members. Why?

There are a couple of (related) reasons.

1. Objects have invariants. Often the values of the member variables will be related to one another in some way. If direct access is permitted to the members of such an object, an invariant may be broken, which would be a bug in your program.

However, some objects are merely collections of data and may not have any invariants. IMVHO, direct access to members of these objects usually isn't a big deal.

2. However, making member objects private adds a level of encapsulation and may protect you from future implementation changes. Let's look at a really silly example. Say you have an object that stores the name of a Person.

class Person{    public:        string name;};

All over your code you use person.name to access the name of a Person. But you soon discover that it would actually be better to store the parts of a Person's name individually.

class Person{    public:        vector<string> names; // first, middle and family name(s)}

Now you have to go and change all your code to deal with person.names instead of person.name

But if we instead started with:

class Person{    public:        string Name() const; // returns name_    private:        string name_;};

we're still ok if we change the private data:

class Person{    public:        string Name() const; // joins the strings in names_ together    private:        vector<string> names_;};

We don't have to go and replace all the places where we accessed a person's .name directly. Instead we only have to change one piece of code -- the Person::Name() function.

Quote:
I mean, I am the one who codes the code, and if I don't want class X to access class Y members, I just won't code it.

Will you always be the only one with access to your code? Where are these rules written down? Will you remember to obey them 6 months down the road?

Of course, you could add a comment, but making a variable private is a stronger kind of comment, one that the compiler can help you to enforce.

Finally, some people would say that having too many Get/Set methods is a sign of a potentially bad design; an object in the OO sense is defined by it's data and behaviour. Lots of Get/Set methods might imply that you've concentrated too much on the data part, but not enough on the behaviour part. In the end, you'll make up your own mind with the benefit of more experience.