.. | ||
src | ||
README.md |
Design of Class Member Variables
The reason that there was a need for the fix to pos_ was due to an assumption on my part about the design of the ArenaEntity. I did not look at it closely enough and assumed setters and getters were implemented polymorphically. Through testing it was discovered that the setters and getters were not working when upcasting. It raises interesting questions about the design of inheritance.
By defining member variables only in the parent class and making them private, the user of the class is forced to use the setters and getters, rather than having direct access to the member variables.
Questions:
- Explain why overriding the variable position_ and its getter in the non-virtual version does not work.
- Explain why position_ must be protected, rather than private in the virtual (polymorphic) version.
- Draw a picture of each version of a robot, including all objects enclosed. Show where the member variable position resides within the objects.
- Imagine the non-virtual version, but with the replacement of position and get_pos in that class (i.e. like the version that was in the class-repo). Draw that robot.
- Identify the advantages and disadvantages of each version (not the incorrect one). Consider robustness and other programmers using the code.
- Heading and speed are stored inside of the motion_handler_, yet these values are sometimes needed outside of the class (e.g. when being drawn). Notice that there is a setter and getter for these variables in the robot class, yet they are not member variables of robot. What do you think about this design with respect to both robustness and use by other programmers. Do you think heading should also exist in robot and somehow be maintained between the motion_handler and the robot class?