🚀 go-pugleaf

rick@tetrauk.UUCP (Rick Jones) writes:

>There are two problems here.  The last paragraph suggests that the author of a
>component decides what may inherit from it, and how.  In other words the scope
>of re-use is being fixed in the design of the component.  Although some
>object-oriented languages encourage this viewpoint (C++ being one of the worst
>offenders, IMHO), for re-use to be valuable in the long-term classes need to be
>re-usable in ways which the original author never envisaged.

I'm not sure of what you are accusing C++ here.  It is possible to define
a C++ class in such a way that it is hard to re-use, but it is not
necessary to do so.  Using C++ terminology: Some languages, such as Eiffel,
make all member functions virtual, and so can be adjusted for any derived
class, whatever the original desinger envisioned.  In C++ you may make
all functions virtual if you wish.  If run-time efficiency is more important,
you can eliminate the overhead of virtual function calls.  A later user
may acquire the source code, change declarations in just one place per
function to add the keyword "virtual", and recompile.

>an object of the sub-class must be prepared to do everything its parent can do
>- it can't refuse to inherit some of its parent's behaviour.  This means the
>object exhibits total conformance to its parent...
>classes and types as synonymous making type conformance checking nice and easy.
>This approach doesn't always reflect reality, though.  You often do want an
>inheritance which says "A is like B except ...", meaning the sub-class is NOT
>going to conform to some aspects of its parent....

Again, you can do this in C++.  It is possible to eliminate some of a
base (parent) class's functionality within a derived (sub) class.  You
simply override the base class function in the derived class with an
empty function which is private.

While I understand your example, I don't agree it is good design.  You
have an "extend" operation for a rectangle which changes its aspect
ratio, something not possible for a square.  I suggest instead something
like this inheritance graph:

			quadrilateral
			______|______
			|           |
		rectangle	trapezoid
		____|____
		|       |
extensible_rectangle	square

Now there is no need to suppress a parent's functionality.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com