Re: Warning
Michael Doubez wrote:
Inheritance in the OOP sense, i.e. (arguably) to reuse a class
implementation in order to *add* to its interface (not modifying its
internals, that's polymorphism).
One could say that there are two schools of thought about inheritance:
The "extends" faction and the "specializes" faction (although they are
not necessarily mutually exclusive). There's a subtle difference between
the two ways of thinking about inheritance.
In the "extends" school of thought inheritance is seen as taking a
class and adding more functionality to it. It's also related to code
reuse: If two classes have common functionality, the common
functionality can be grouped into a common base class, and then the two
classes can inherit from it (so, in effect, the two classes are now
extending the base class functionality in two different ways, while
having the common functionality in one place, thus avoiding code
repetition). Thus when you inherit you could say "DerivedClass extends
BaseClass".
The "specializes" school of thought is more related to object-oriented
design. This is where the concept of the "is-a" relationship comes from.
Here a class is a concept, and there's a scale of abstraction between
concepts: Some concepts are more abstract and generic, while others are
more concrete and specialized. For example, in a GUI framework you could
have a class named "Widget", and several classes derived from it, eg.
"Button" and "Label". In this case "Widget" is a more generic and
abstract concept, while "Button" and "Label" are more concrete concepts.
In other words, they are Widget specializations. Thus one can say that
"Button is-a Widget" and "Label is-a Widget". However, Button is *not* a
Label. What this means in practice is that wherever an object of type
Widget is expected, an object of type Button or Label can be given
instead (because a Button *is* a Widget, as well as a Label *is* a
Widget). However, if a Button is expected, a Label cannot given to it
(because a Label is *not* a Button). Thus when you inherit you could say
"DerivedClass specializes BaseClass" (ie. creates a more concrete
concept from it).
The "specializes" school of thought is not mutually exclusive with the
"extends" one. One could say that the latter is just a side-effect of
the former, and could be used (or "abused") for that purpose.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---