|You don't want to expose your variables. |
But one should provide some sort of interface.
Scott Meyers talks about get / set functions in his book "Effective C++ 3rd Edition" Item 22 "Declare members Private" :
|If you make data members public, everybody has read-write access to it, but if you use functions to get or set it's value, you can implement no access, read only access, and read write access. |
However, he also said:
|Such fine grained access control is important because many data members should be hidden. Rarely does every data member need a getter and setter.|
I did say not to get carried away with getters / setters.
We had a discussion about this a while back. I was asking how to avoid having protected data (make it all private instead). cire
was saying that base classes should have a complete interface so that variables in it can be set from a derived class. He also said that get / set functions increase encapsulation.
I can understand how having get / set functions can break code just the same as public / protected data, but I can't help thinking there are exceptions. And can the change in type be handled with templates - for example rectangle data changes from int to double.
Part of what I was asking in my post back then was about "Future Proofing" data. It seems to me that to do this effectively, one has to upgrade the variable to a class, or use a design pattern. Scott Meyers has examples about that. An example from your link:
|Today an "identity" is a name; tomorrow it's a name and ID number; the day after that it's a name, ID number, and picture.|
This might be a bit much for a beginner - although it won't hurt to have it in mind.
What about all these questions:
Is it unreasonable to be able to enquire what a circle's radius is? Are length & size functions in the STL not getters? Is a move or rotate function in a drawing object class not a setter in disguise? How would you implement a move function otherwise? By template is still the same thing - a setter in disguise. What if I want to change only the Z value? I can think of lots of examples in geometry - another is draw a tangent line between point or circle drawing objects.
I should say that one has to be careful not to invalidate the other variables - for instance one shouldn't change the centre point of an arc without recalculating everything else. But that is the responsibility of any function doing any updating.
|Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.|
How does this work this situation using the physics scenario, where the work to be done is related to other objects as well:
Say we have 2 physical objects of different types which are subject to events that effect their velocity vectors (Direction & Speed). You want to calculate when & where they collide. To do this you must obtain the data from each object in order to make the calculation.
Whether another class is responsible for the calculation, or it is being done in one of the objects, or with a design pattern: there is no difference, one must "get" the data.
Is this scenario an exception to what is in the article?
|There is no `one class per file' rule. But group them in a logical way.|
OK, there is no hard rule about that - but I would strongly suggest that it certainly makes sense, and that it seems to be standard practice. If one has class declaration for classes A & B in 1 file, and that file is included somewhere - then you get both when you may have only wanted one. Having 1 per file with the same name is the most flexible & sensible IMO. Not having the same name really is confusing.
> You also have implementation code in your headers which is evil.
Unless they are inline or template, having function definitions in headers will cause `multiple definition' error.
I very much doubt if an experienced developer would put inline functions in a header, unless it was a very short explicit one - say with just a return statement - a getter?! . This all comes about because beginners see book authors lump all the code into 1 file - so they continue that idea until they learn otherwise.
Hopefully all this is not too much for the OP - there is often more than meets the eye with C++.