Database Design Puzzle: What's wrong with this diagram?

I'm trying to polish up by database design skills. I've been working through a few IT-related puzzles today, most of which have been fairly straightforward. ...And then I came across this supposed 'oldie', which is frustrating the bezeejers out of me.

The premise is that there's an error with the class hierarchy in the diagram below. No further information regarding the na开发者_JAVA百科ture of the classes/interface is given. I cannot find any logical issue with it. The best I can do is whimper that a point is not technically a shape, but I'd like to think the answer is a little less weaselly than that.

If anyone has any suggestions, I'd love to hear. It really is doing my head in.

---

Perhaps the question is giving us a hint:

No further information regarding the nature of the classes/interface is given.

We have absolutely zero information about the actual scope (i.e. business logic) of the problem. "Shape" could be a mathematical representation to be drawn on a grid. It could be a definition for a game engine modelling program. It could be an indicator of a person's fitness level. Who knows? Each of those variants would require different representations in both class diagrams and a relational data model.

It leaves us only to make assumptions about what might be semantically wrong. However, we can make observations about what might be technically wrong with the diagram itself.

I pose the problem is that the arrows are pointed in the wrong direction. In most class diagrams, inheritance is denoted by the child class having an arrow pointed at the base class.

---

This answer may seem nonsensical. However, it's actually meant as a jab at the puzzle question itself. In real life, designing anything (databases, class diagrams, whatever) is about taking the business-specific needs of the problem and making the appropriate design decisions. Without knowing anything about the domain, all we can do is make assumptions about what might be semantically wrong with the design, which makes for a rather pointless puzzle problem.

---

I think the Polygon class is redundant. Is there any special reason why you'd have to separate rectangle and square? Going even further, why differentiate triangle from a rectangle? You could think of both as just a list of points; triangle has three, rectangle has four. And there's the thing you've mentioned yourself; point is not really a shape and maybe that's the most obvious answer you're looking for.

---

I'm stumped too. The only thing I can come up with is that Polygon and Ellipse should be subordinate to Point.

A Polygon is three or more points.

An Ellipse has two focal points.

That would make the Shape interface a list or array of points.

---

Your question refers to database design and this is where I see the problem; The class hierarchy is far too deep and in my opinion could be modelled using a single shape class as all share similar properties E.G. all have sides. A circle has one, a triangle has 3 and a rectangle has 4.

As far as the class diagram itself goes I guess it could be argued that point, polygon and ellipse should be interfaces rather than classes.

I also agree that with the other comments about point not being a shape.

Out of interest where has this question originated from?

---

If I were to look at this from a rigid mathematical perspective, Point and Ellipse/Circle are Conic Sections, and should be in the same class. I don't know that's the magical answer being looked for, but it is one.

Extending that, a Polygon consists of 3-N Lines, which aren't a portion of the data model.

I would agree with the other posters who point out that Circles, Rectangles, and Squares are simply special cases of Polygon, and I would not have broken them out specifically in a relational database model. This may make sense for an object model, but it appears to be overkill for a relational one.

---

Given the vague nature of the question, this sounds like it could be a phrasing of the circle-ellipse problem. http://en.wikipedia.org/wiki/Circle-ellipse_problem.

Essentially the error would be defining sub-classes which have invariants that can't be defined in the super-classes:

• To define a valid square, you have to maintain a height-width ratio that isn't required in a rectangle (in the general case)
• Ditto (roughly) circle and ellipse

Related discussion at Is deriving square from rectangle a violation of Liskov's Substitution Principle?