Class hierarchy

[Piotre Ugrumov]

I would have to implement a class hierarchy.
The base class is the class Quadrilateral.
The discendents arre th classes Trapezoid, Parallelogram, Rectangle, Square.

Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square
The class Quadrilateral takes the cordinates of the four vertex.
What must I implement in the other classes?
In the trapezoid what do I insert?
Thanks.

[Bryan Bullard]

"Piotre Ugrumov" <au************@tin.it> wrote in message
news:%I********************@news4.tin.it...

is this your course homework?

I would have to implement a class hierarchy.
The base class is the class Quadrilateral.
The discendents arre th classes Trapezoid, Parallelogram, Rectangle, Square.
Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square
The class Quadrilateral takes the cordinates of the four vertex.
What must I implement in the other classes?
In the trapezoid what do I insert?
Thanks.

[Jeff Schwab]

Piotre Ugrumov wrote:

I would have to implement a class hierarchy.
The base class is the class Quadrilateral.
The discendents arre th classes Trapezoid, Parallelogram, Rectangle, Square.

Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square
The class Quadrilateral takes the cordinates of the four vertex.
Is there a practical reason to do this? The fact that a square is a
rectangle does not mean that class Square must be derived from class
Rectangle. This sort of design is typically inefficient. The reason is
that the derived classes don't need the generality that likely will be
provided by the base class. For example, you said Quadrilateral "takes"
four vertices. If those vertices are stored in member variables, then
by deriving Square from Quadrilateral, you force Square to remember all
four vertices. These members will be wasted in Square, since a Square
can be defined by one vertex and a side length.
What must I implement in the other classes?
In the trapezoid what do I insert?

In order to do what? For what do you expect to use these classes?

-Jeff

[Cy Edmunds]

"Piotre Ugrumov" <au************@tin.it> wrote in message
news:%I********************@news4.tin.it...

I would have to implement a class hierarchy.
The base class is the class Quadrilateral.
The discendents arre th classes Trapezoid, Parallelogram, Rectangle, Square.
Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square
The class Quadrilateral takes the cordinates of the four vertex.
What must I implement in the other classes?
In the trapezoid what do I insert?
Thanks.

Assuming that this is a homework problem (otherwise I would quibble with the
design) I would say that you could implement this heirarchy with classes
which differ only in their constructors. For instance:

class Square : public Rectangle
{
public:
Square(double x0, double y0, double x1, double y1) :
Rectangle(x0, y0, x1, y1, x0+y1-y0, y0+x1-x0) {}
};

Here I have assumed that the constructor for a Rectangle takes three points,
the fourth being computable from the first three.

--
Cy
http://home.rochester.rr.com/cyhome/

[Roger Leigh]

"Cy Edmunds" <ce******@spamless.rochester.rr.com> writes:

Assuming that this is a homework problem (otherwise I would quibble with the
design) I would say that you could implement this heirarchy with classes
which differ only in their constructors. For instance:

class Square : public Rectangle
{
public:
Square(double x0, double y0, double x1, double y1) :
Rectangle(x0, y0, x1, y1, x0+y1-y0, y0+x1-x0) {}
};

Here I have assumed that the constructor for a Rectangle takes three points,
the fourth being computable from the first three.

This assumes that the square is positioned relatively, since it's not
obvious which vertices you have specified. If this assumption is
correct, you could simply have "Square (double v)" as the constructor,
just specifying the line length of one side--you can compute the
vertices in the constructor. Also, if you're always using vertices, a
Vertex class would be handy, too.
--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.

[osmium]

Jeff Schwab wrote:

Piotre Ugrumov wrote:

I would have to implement a class hierarchy.
The base class is the class Quadrilateral.
The discendents arre th classes Trapezoid, Parallelogram, Rectangle, Square.
Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square
The class Quadrilateral takes the cordinates of the four vertex.

Is there a practical reason to do this? The fact that a square is a
rectangle does not mean that class Square must be derived from class
Rectangle. This sort of design is typically inefficient. The reason is
that the derived classes don't need the generality that likely will be
provided by the base class. For example, you said Quadrilateral "takes"
four vertices. If those vertices are stored in member variables, then
by deriving Square from Quadrilateral, you force Square to remember all
four vertices. These members will be wasted in Square, since a Square
can be defined by one vertex and a side length.

> What must I implement in the other classes?
> In the trapezoid what do I insert?

In order to do what? For what do you expect to use these classes?

Amen! This is a truly disgusting assignment. It is wasteful of memory and
human neurons. It gives the student no insight whatsoever into inheritance
and and how it might be useful instead of an impediment to doing something
interesting and perhaps even useful.

To the OP: {I have read your second post too, the link here is not
chronological)

Presumably, at some point you will be able to compute the perimeter and area
of these four plane figures. That seems a reasonable goal. But it seems
you need some context. IOW, are you (main) to be given four vertices and
determine *what* to construct? Or are you given two vertices and told that
this is to be a square? Looking at your code I see you assume main gets
four vertices and the additional information in the name of the resulting
figure. It sounds a bit like cheating (no insult intended) but someone has
to go through hell to call the constructor and then the thing you wrote goes
through another hell to unwind this complicated mess. Do you see my point?

That is, what is the nature of the *driving* program/problem/whatever? One
candidate: you are given four vertices and told it is a square. Your code
determines if it is indeed a square or if the caller had lied to you. And
proceeds accordingly.

[Cy Edmunds]

"Roger Leigh" <${******@invalid.whinlatter.uklinux.net.invalid > wrote in
message news:87************@wrynose.whinlatter.uklinux.net ...

"Cy Edmunds" <ce******@spamless.rochester.rr.com> writes:

Assuming that this is a homework problem (otherwise I would quibble with the design) I would say that you could implement this heirarchy with classes
which differ only in their constructors. For instance:

class Square : public Rectangle
{
public:
Square(double x0, double y0, double x1, double y1) :
Rectangle(x0, y0, x1, y1, x0+y1-y0, y0+x1-x0) {}
};

Here I have assumed that the constructor for a Rectangle takes three points, the fourth being computable from the first three.
This assumes that the square is positioned relatively, since it's not
obvious which vertices you have specified.

No, I did not assume the square is positioned relatively. In fact I gave
three of the vertices explicity. The three vertices specified are (x0,y0),
(x1,y1), and (x0+y1-y0,y0+x1-x0). The fourth must be (x1+y1-y0,y1+x1-x0),
but that is for Rectangle's constructor to figure out.

From the OP's initial post:

"The class Quadrilateral takes the cordinates of the four vertex"

Thus we need to specify each vertex explicitly for each derived class.
Otherwise when we get to the top of the heirarchy we won't know what to do.
If this assumption is
correct, you could simply have "Square (double v)" as the constructor,
just specifying the line length of one side--you can compute the
vertices in the constructor. Also, if you're always using vertices, a
Vertex class would be handy, too.
Yes, a Vertex class would be a good idea.


--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your

mail.

--
Cy
http://home.rochester.rr.com/cyhome/

[EventHelix.com]

> Quadrilateral

|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square

You can define constructors for each class with lesser number of
parameters and then invoke the base class constructor that
takes four parameters.

The main issue with the hierarchy is that it violates the Liskov
Substitution Principle. See the following article:
http://www.eventhelix.com/RealtimeMa..._principle.htm

Any code that has been written with the Quadrilateral base class might
break if, say, a Square object is passed to it. The Square is a
specialized
Quadrilateral. So code like changing length and width independently
will break.

Hope this helps.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Go Beyond UML Use Case and Sequence Diagrams

[Jeff Schwab]

EventHelix.com wrote:

Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square

You can define constructors for each class with lesser number of
parameters and then invoke the base class constructor that
takes four parameters.

The main issue with the hierarchy is that it violates the Liskov
Substitution Principle. See the following article:
http://www.eventhelix.com/RealtimeMa..._principle.htm

Any code that has been written with the Quadrilateral base class might
break if, say, a Square object is passed to it. The Square is a
specialized
Quadrilateral. So code like changing length and width independently
will break.

Hope this helps.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Go Beyond UML Use Case and Sequence Diagrams

That's interesting.

By the way, none of the classes in the temperature-sensor "hierarchy"
inherit anything. Did I miss something?

[Roger Leigh]

Jeff Schwab <je******@comcast.net> writes:

EventHelix.com wrote:

Quadrilateral
|_
Trapezoid
|_
Parallelogram
|_
Rectangle
|_
Square

You can define constructors for each class with lesser number of
parameters and then invoke the base class constructor that
takes four parameters.
The main issue with the hierarchy is that it violates the Liskov
Substitution Principle. See the following article:
http://www.eventhelix.com/RealtimeMa..._principle.htm
Any code that has been written with the Quadrilateral base class
might
break if, say, a Square object is passed to it. The Square is a
specialized
Quadrilateral. So code like changing length and width independently
will break.
Hope this helps.
Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Go Beyond UML Use Case and Sequence Diagrams

That's interesting.

By the way, none of the classes in the temperature-sensor "hierarchy"
inherit anything. Did I miss something?

If I understand correctly, if the design must meet the Liskov S. P.,
the base class should provide virtual methods to get/set each vertex,
and then each derived "shape" should override them such that the other
vertices are readjusted to contrain the quadrilateral to their shape?
--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.