Figure 1: First version of inheritance graph.
Peter Müller
Saifi has sent to me three suggestions of how the inheritance graph of the classes DrawableObject, Point, Circle, Rectangle, 3D-Point and Sphere might look like.
I'd like to present some comments and two additional suggestions. But first, after discussing these suggestions with some of my colleagues we came up to the opinion that there is no right answer. The answer highly depends on the environment in which the objects (of these classes) should be used. Consequently, the environmental settings usually urge a specific inheritance graph.
Figure 1 shows Saifi's first suggestion. Here, Sphere is derived from both 3D-Point and Circle. With our discussion about multiple inheritance, this solution makes only sense if Point is derived only once. It should not result in an inheritance relationship in which a Sphere object has two copies of Point instances. Otherwise there would be no unique reference point.
Figure 1: First version of inheritance graph.
Let's refer to an inheritance scheme in which Point instances would only exist once in an object of a multiply derived class as virtual. However, if class Sphere is virtually derived from Point why not also derive Cuboid from Rectangle (and thus virtually from Point)? Saifi's third suggestion shown in Figurer 2 does exactly that.
Figure 2: Second version of inheritance graph.
The third (and Saifi's second suggestion) is a little bit strange, because Sphere inherits directly from Circle (Figure 3). This would require Sphere to add a coordinate for the third dimension. Consequently, there would be no identifiable reference point! Its coordinates would be distributed across Circle and Sphere. And this would not enable us to uniquely reference a Sphere as we could with the other objects.
Figure 3: Third version of inheritance graph.
Figure 4 shows the inheritance graph which I had in mind when I wrote the excercise. It makes no use of multiple inheritance and just covers the fact, that I want each object to have a reference point.
Figure 4: Fourth version of inheritance graph.
When I discussed this with one of my colleagues (who is mathematically oriented) he stated that he would divide the set of classes/objects into 2D and 3D-objects. This is because both types require a different ``space''. This would lead to an inheritance graph as shown in Figure 5.
Figure 5: Fifth version of inheritance graph.
In the other hand, if we talk about object-orientation and want to reuse as much as possible, we could argue for all versions which let 3D-Point inherit from Point. For example, assume that Point defines a method to move around:
class Point {
attributes
int x, y
methods
move(int dx, dy) {
x <- x + dx
y <- y + dy
}
...
}
If we let 3D-Point inherit from Point we could formulate a move method in 3D as:
class 3D-Point inherits from Point {
attributes
int z
methods
move(int dx, dy, dz) {
Point::move(dx, dy)
z <- z + dz
}
...
}
Here, 3D-Point::move() reuses the move method of Point. Graphically interpreted, we first move a 3D object in its xy-plane and then move it in z-direction.
There exists no correct answer but intuitive and argueable ones. For example, solutions 2, 4 and 5 are, in my opinion, intuitive.
Discussion of Excercise 5.5.1d
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -html_version 3 -no_navigation -t Excercise 5.5.1d main.tex.
The translation was initiated by P. Mueller on Wed May 14 10:37:02 MST 1997