TITLE: Class design for lines and vertical lines PROBLEM: pickerig@eee.bham.ac.uk (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: rmartin@rcmcon.com (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: maxtal@physics.su.OZ.AU (John Max Skaller), 2 Jun 93 Warning bells 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.