This is one of the boring academic OOP questions, but it is not a homework. I got the question from a newbie programmer about one of those stupid textbooks examples about OOP.
Imagine that you are designing a Square class and a Cube class, which should inherit which?
I see a relationship, but what it is, I can not really see!
Could you give me a logical argument with OOP in mind.
Neither! Since a square is not a cube, and a cube is not a square, neither should inherit from the other. Square can inherit from polygon and cube can inherit from polyhedron, but the two are, themselves, mutually exclusive.
There's no inheritance. Inheritance is a "is-a" relationship (Well, sometimes not even a "is-a" relationship, as mentioned in the link below). A cube is not a square, and a square is not a cube.
How would you construct, it depends on how you model. You could go with something like a cube has 6 squares (a cube is not, it has 6 squares; a composition), or a cube has a side size, just like square. But once there is no "is-a", an inheritance would be dangerous zone...
Also, in a inheritance, everything that is valid for the base class must be valid for the Derived one. It's the Square extends Rectangle problem. For instance:
Supposing Cube inherits Square: If your Square has a method changeArea(double area) and getSide(), the same should be possible for the Cube. But it is not, since the area of a cube is 6 times the area of a square (it has 6 squares).
Supposing Square inherits Cube: If your Cube has a setVolume(double volume) method, your square will be broken, once it has no volume
Finally, if you want to use inheritance, you could create a GeometryObjectWithEqualSides object, then both could inherit from it. :)
Neither should inherit the other. One is a 2-dimensional shape, the other is a 3-dimensional object. There really isn't enough similarity between the two to justify inheritance.
Now you might conceivably make a cube composed of squares, if you need a separate object for each side ;)
Having it either way would be a violation of the Liskov Substitution Principle.
struct Square // Rectangle actually
{
Square( int dx, int dy ) : dx(dx), dy(dy) {};
int dx;
int dy;
int floor_area() { return dx*dy; };
};
struct Cube : Square // Cuboid actually
{
Cube( int dx, int dy, int dz ) : Square(dx, dy), dz(dz) {};
int dz;
int cube_area() { return floor_area()*2+dx*dz*2+dy*dz*2; };
};
Seems to be that Liskov substitution principle is not violated here.
Most of comments here are correctly saying that none of them should inherit from another. This is true in most cases. But I think there is more generic answer: It depends on your expectations on them. You expect Square to do what? Does Cube also do it? May be the other way - can you use Square whenever you use Cube? I think both statements "Cube does all what Square does" and "Square does all what Cube does" are false, according to common sense, so none of them should inherit from another. However, it is up to you to decide their structure and behavior, because it is you who defines what your program does and what it consists of.
Most likely "Cube contains 6 Squares" is the relationship that you saw.
The square and the cube could be argued to be two instances of the same class "Hypercube" which would also encompass the point (0 dimensions), the line segment (1 dimension) and others beyond that. The number of dimensions and the length of one side are enough to define a specific instance of Hypercube (you could of course add an n-dimensional point of origin and orientation).
The hypercube could provide functions/methods that return values for the number of vertices, edges, faces, etc. for that particular instance.
See Hypercube on Wikipedia for more info.