I guess that all quadrilaterals (which I believe to be poligons of 4 sides) are poligons. so I would say that quadrilateral should be a subclass of polygon.
A rectangle is a particular quadrilateral, so as rectangle are quadrilaterals then the rectangle class should be a subclass of quadrilateral.
So you would have that rectangle is a subclass of quadrilateral and quadrilateral is a subclass of polygon.
My questions are:
What problems could arise by making Quadrilateral and Rectangle subclasses of Polygon? What alternatives are possible? What are the advantages and disadvantages of each alternative?
You're getting close to a classic example of the limitations of single inheritance.
A parallelogram is a quadtilateral, so we can have Parallelogram extend Quadrilateral.
A trapezium is a quadtilateral, so we can have Trapezium extend Quadrilateral.
But a rectangle is a parallelogram and a trapezium, so what do we do now?
I don't think there's an absolute answer to this, so the best approach is going to depend on what you're trying to achieve. Which means I don't think you can necessarily design a perfect hierarchy in isolation.
To put it another way, when you're doing object-oriented analysis and design, you need to balance the "academic" part of figuring out IS-A, HAS-A, etc. relationships with "practical" considerations of what you want to do. The end goal is not really to arrive at a perfect Object-Oriented model that follows ALL the object-oriented rules. Rather, your goal needs to be to come up with a design that is loosely coupled and has responsibilities assigned appropriately to objects that can carry out those responsibilities coherently.
In my experience, it's far more useful to develop your design along with tests and code. Design is an idea, a hypothesis of how the system should work. Tests and code help you verify your idea. if you don't see your design form up as working code, it's very difficult to go through the trial and error process that is needed to refine a design (the idea) into something concrete (working code).
That's why I like Test-Driven Development because it's as much about design as it is about testing and coding.