Re: Very Confused on Page 33

From: Matt Humphrey (matth_at_ivizNOSPAM.com)
Date: 01/29/05


Date: Sat, 29 Jan 2005 11:36:36 -0500


"eBob.com" <eBob.com@totallybogus.com> wrote in message
news:dsOKd.192$sd.38@fe10.lga...
> I am only on page 33 of Bruce Eckel's "Thinking in Java" and I am so
> confused by one point that I can go no further without getting this
> straightened out. On page 33 Bruce is explaining inheritance. The text
> which confuses me is " ... all the messages you can send to objects of the
> base class you can also send to objects of the derived class. Since we
know
> the type of a class by the messages we can send to it, this means that
THE
> DERIVED CLASS IS THE SAME TYPE AS THE BASE CLASS. ..." (emphasis added)
>
> I am not totally unfamiliar with OOP and I understand that all messages
> which can be sent to objects of a base class can also be sent to objects
of
> the derived class. BUT, I would think that, in general, the inverse is
not
> true. Without getting into what the meaning of is is, am I supposed to
> understand that the derived class is the same type as the base class, but
> the base class is not the same type as the derived class?

Yes, this is very much a problem of semantics. Every object is a *specific*
instance of exactly one class. However, because classes can inherit
properties in a hierarchical fashion, we can say that an instance of a
derived class can be treated as if it were an instance of the base class.
In fact, we can even say an instance of a derived class is an instance of
the base class (e.g. the instanceof operator, etc) And, as you rightly
understand, an instance of the base class is not an instance of this or any
other derived class and it cannot be treated as if it were.

> But even if that would resolve the confusion which I have explained so
far,
> what about "Overriding base-class functionality" - the topic which is
> comming up at the bottom of the page. Even assuming that "the derived
class
> is the same type as the base class" is not meant to be a symmetric
> statement, is it true even though the derived class might have overridden
> functions? I would think that the compiler would need to be able to
> distinguish between objects of the base class and objects of the derived
> class. How would it do that if they both are of the same type?

As noted above, runtime environment keeps track of the specific class of
each object--it is an immutable property of each object. What changes is
the programmatic meaning or behavior of any property in a derived class. A
subclass may have a method that overrides one in the base class and which
programmatically behaves differently. (One of the main advantages of OOP is
that methods in the derived class that are programmatically identical to
those in the base class do not have be written at all--they are simply
inherited to be the same.) The programmatic difference enables the subclass
to fulfil the contract of the base class for whatever difference is intended
by the subclass. For example, the base class may be Mammal and the method
is "speak()". The subclass "Dog" implements this with some kind of bark and
the subclass "Cat" implements it with some kind of meow. They both fulfil
the same purpose of the speak method but in necessarily different ways.

Cheers,
Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/



Relevant Pages

  • Re: LoadString overwrite
    ... base class doesn't have a virtual destructor. ... derived class, thinking they are "overriding" them, because they are not. ... Clearly if a class doesn't have a virtual destructor, ... However there are lots of things you can do using inheritance quite apart ...
    (microsoft.public.vc.mfc)
  • Re: Writing bulletproof code
    ... This support already exists. ... > In fact inheritance is most frequently used to extend a type with ... > A subclass inherits the data and virtual methods of its base class. ... > subclass a superset of the base class, not a subset of the base class. ...
    (comp.programming)
  • Re: Application.Run() problem
    ... still am very much confused about the paint event handler. ... It most obviously should be the derived class, ... It seems that you're not understanding how inheritance works. ... which ensures that the base class uses the same ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Inheritance question
    ... Changing visibility in this way would break that - ... suddenly your subclass does not *really* expose the interface of your base ... One option you do have is to make the properties of the base class ... instead I'm using 2 classes and inheritance to keep the generated code ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: attribute or subclass
    ... With inheritance the derived class code ... reference in place of the base class reference. ...
    (comp.object)