On Mar 9, 2013 7:20 AM, "Calvin Bornhofen" <calvin.bornhofen / web.de> wrote:
>
> Hello,
>
>
> On 08.03.2013 19:26, john rxjmo wrote:
>>
>> I think I'm confused before your post :).
>> I thought that the goal of subclasses is the ability to add more methods
>> than the ones in the super class.
>>
>> Thank you for your help.
>
>
> by expanding on the subclasses you add information, yes, but that doesn't
affect the parent class.
>
> Kind regards,
> Calvin
>

Indeed. The point of a subclass is to create a *new type* of object, which
refines or specialises or builds on an existing type.

For example, you could have the following class hierarchy:

vehicle > land_vehicle > car

All vehicles share some common code, properties, and methods; but cars have
some that planes and trains don't. Modifying 'car' cannot affect 'vehicle'
or 'land_vehicle' without also affecting planes and trains.

What makes it a bit more complex is that in this case it's possible (and
presumably sensible) to instantiate a 'vehicle' directly, and have that
object be a fully functioning transporter. Thus land_vehicle and car are
*specialising* vehicle (restricting the domain, for example limiting it to
only land-based travel).

Now in this case there seems to be some parallel hierarchy going on;
extending the metaphor, it's as though vehicle includes a 'driver' object,
but car wants to replace it with a 'car_driver' (and plane with 'pilot',
etc.)  This is a lot trickier; you need to refactor it so that the code in
'vehicle' that instantiates 'driver' can be overridden in the sub-classes,
or something similar.

I find drawing on paper or a whitboard helps.