News:

This week IPhone 15 Pro winner is karn
You can be too a winner! Become the top poster of the week and win valuable prizes.  More details are You are not allowed to view links. Register or Login 

Main Menu

c++ tips - Class design for lines and vertical lines

Started by ben2ong2, October 07, 2006, 04:06:59 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

ben2ong2

PROBLEM: You are not allowed to view links. Register or Login (Guy Pickering)

If I have a class Line:

  class Line
  {
    public:
      Line( const Point& a_p0, const Point a_p1 );
      //...
      Point p0() const;         // returns start point.
      //...
      void p0( const Point& a_p0 );   // sets start point.
      //...
  };

I want to derive a class Vline which is a vertical line. The ctor
will take a starting point and a length and calculate the start and
end points. Obviously I do not want to allow all the point setting
functions in Line to "corrupt" the Vline. I wish to enforce
that the two points must have the same X value.


My question is this: How should I achieve this?

  a) privately derive Vline from Line, making some members
     public within Vline?

  b) make all members of Line virtual and override in Vline?

  c) Do not derive from Line at all?



RESPONSE: You are not allowed to view links. Register or Login (Robert Martin), 1 Jun 93

Suppose you had a function:  Rotate(Line&, int angle);  If Vline were
publicly derived from Line, and if you passed a Vline into the Rotate
function, the results would be strange.  Certainly no rotation could
take place.

My point is that a Vline does not behave the way a Line does, so it
should not be publicly derived from Line.  To do so could confuse the
functions that take Line objects as arguments, and could proliferate
some kind of RTTI checking within those functions.

At least from the point of view of the Clients of Line, a Vline IS NOT
a Line.

[option a]

This is a possibility.  You can reuse much of the Line class in Vline
without asserting that Vline ISA Line.

[option b]

Ack! No.  If Vlines are passed to functions which expect Lines, then
those functions could be confused by their odd behavior (e.g. always
remaining vertical.) 

[option c]

This is the other possibility.  It depends upon how much code in Line
can be reused.  If it is not very much, then forget about deriving and
make the two classes independent.

There is another possibility:

class LinearObject...
class Line : public LinearObject
class Vline : public LinearObject


A LinearObject is the factoring of Line and VLine.  Clients of
LinearObject expect only those behaviors which are common to both
objects.  (i.e. they can have a slope, they can have a length, they
have two endpoints, etc.....)


RESPONSE: You are not allowed to view links. Register or Login (John Max Skaller), 2 Jun 93

   Warning bells <ding, ding>

   public inheritance is dangerous!

   LinearObject is not abstract above (it it were, it would
have been a virtual base : abstractions should almost *always* be
virtual bases).

   So we had better ensure that given:

   Vline V = ..
   LinearObject L = V;

that L is the same line as vline is, that is, any state in
Vline cannot be used to represent its 'linear-ness' (Unless
it only caches things or optimises state in Line).

   What purpose would a Vline have? Well, one use is
to allow a contructor that guarrantees a vertical line:

   Vlline(Point p, float len) : Line(p, Point(p.x, p.y+len) {}

which could sensibly be used like this:

   LinearObject L = Vline(p,l);

in other words, Vline is just a function that creates an instance
of LinearObject that happens to be vertical initially.



You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login