File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes OO, Patters, Polygon (Quadrilateral and rectangle) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OO, Patters, Polygon (Quadrilateral and rectangle)" Watch "OO, Patters, Polygon (Quadrilateral and rectangle)" New topic

OO, Patters, Polygon (Quadrilateral and rectangle)

Mikie Smith

Joined: Sep 14, 2012
Posts: 4
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?


Matthew Brown

Joined: Apr 06, 2010
Posts: 4543

Hi Mikie. Welcome to the Ranch!

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.
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

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.

Junilu - [How to Ask Questions] [How to Answer Questions]
I agree. Here's the link:
subject: OO, Patters, Polygon (Quadrilateral and rectangle)
It's not a secret anymore!