My book says that one should try to keep all member variables in private in a class. And then you public functions to get them outside the class. I was just wondering what the argument for that is. I've read that it's suppose to be "safer", but I dont understand in what way it's safer and why.

After what I've learned a class should look like this:



I also will have to 8 more setXXX(...) functions in order to change the member variabels. If the member variables would have been public then I would have 16 less functions to worry about ... Please explain why I shouldn't do it that way.

Thanks,
simpler [smile]

The thinking goes something like this:
Imagine your class has an "area" public member. Now you and your team use the class for a few weeks and in a bunch of places. Then you want to change it to calculate the area instead to save memory - minor nightmare to change all the dependent code. This is even worse if you created a library that people you've never met are using.

Another case is if you had a "height" member, and only weeks later do you realize that if someone puts in a negative value it will corrupt all savegames (or something equally horrible). Now you need to add a check for this case, which requires a method and you have a similar issue to above.

You also have the ability to create read-only members by only implementing a getter, or even a write-only.

Btw, creating getters and setters is so common that most IDEs have a shortcut for creating them. You might want to check if yours does.

EDIT: Also, many modern languages have solved this issue with properties, which have syntax like member variables but are actually methods - C++ doesn't have anything equivalent.

You really have to question why you are using an object in the first place. If all you are doing is creating mindless setters and getters, it should be a struct, not a class. When building classes, you should be caring about the overall behavior of the object, not its internal components. The class uses its internal data to achieve a higher motive. Make sense?

Objects have behaviour, not data. When you think about an object you shouldn't have to worry about it's internals. Ideally you write the interface that makes sense at the conceptual level, and shouldn't depend on the exact implementation.

Objects move(), they don't setX() or setY(). Objects generally don't change size (unless you are writing Mario or something). If they do then they will have grow() or shrink() member functions, not setWidth() and setHeight(). Objects don't change types, just create a new Object instead. Objects don't generally change from being static to non-static.

Also, don't store the object rectangle as a member variable. Instead of calling updateRect() and getRect(), simple make getRect() dynamically generate the rectangle. That, or only store the rectange and drop the x,y,width,height member variables.

Why is it safer? Well, Objects have these things called "invariants". An invariant is something that is a predicate that is always true. For example, you might say that an objects width and height are always greater than 0. The objects texture might never be NULL.

By making these variables private, you can vastly reduce the amount of code that accesses them, which makes enforcing this invariant easy. Other invariants are those I've mentioned about keeping certain state immutable. You could of course enforce this using the "const" keyword, but that can make it hard to write copyable objects.

A class without invariants isn't a class, it is just a convenient grouping of data.

Quote:Original post by rip-off
Objects move(), they don't setX() or setY(). Objects generally don't change size (unless you are writing Mario or something). If they do then they will have grow() or shrink() member functions, not setWidth() and setHeight(). Objects don't change types, just create a new Object instead. Objects don't generally change from being static to non-static.

QFE.

Most of the time, when you write a class that significantly features get/set methods, you are really writing a Facade.

Thanks everyone for great answers!

Quote:Original post by rip-off
Objects move(), they don't setX() or setY(). Objects generally don't change size (unless you are writing Mario or something).

You are right about, when I think about it I really don't need them.

Quote:Original post by rip-off
Objects don't change types, just create a new Object instead. Objects don't generally change from being static to non-static.

Hmm I feel a bit confused. Lets say I inherit Enemy from object, shall I then just use



and if I inherit a Platform



Okey, while I wrote that I realised how logical it was, I really dont need the arguments in the ctor [smile].
Because that is how you would do it, right?

Quote:Original post by rip-off
Also, don't store the object rectangle as a member variable. Instead of calling updateRect() and getRect(), simple make getRect() dynamically generate the rectangle. That, or only store the rectange and drop the x,y,width,height member variables.

I allways felt that it was messy having both x,y,width,height and a rect but didn't know what to do about it. Thanks for telling me!

Well, I would avoid storing the type as an enumeration, as the derived class itself can usually do the work if you design it properly.

For example, instead of:

Could be:

You might find double dispatch a good solution for more complex situations, such as collision detection. It works well when the total number of classes isn't massive. But you generally can reduce the total number of classes with a data driven approach and by moving certain behaviour into auxiliary helper classes.

It depends on what you want to do with the "type" member, but building your own type system that isn't in sync with the regular type system can lead to bugs.

The main reason why I have a type member is for collision detection. On a collision the player should check the mType value of the object and then act accordingly.

I don't understand why you don't think I should store a enum representing the type and setting it in the constructor.

But the mStatic you believe is fine to set in the constructor? I will use the mStatic to find out whether or not to update the object. If it is static I only need to draw it.

then how about adding the object to an update list only if it needs updating? sort of the reverse approach: don't store it in the object, but have lists of objects "of a certain feature".