From: Matthew Kerwin Date: 2013-03-09T08:36:57+09:00 Subject: Re: methods in subclasses --bcaec554d43453fc4c04d7724cea Content-Type: text/plain; charset=ISO-8859-1 On Mar 9, 2013 7:20 AM, "Calvin Bornhofen" 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. --bcaec554d43453fc4c04d7724cea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 m= ethods
>> than the ones in the super class.
>>
>> Thank you for your help.
>
>
> by expanding on the subclasses you add information, yes, but that does= n't affect the parent class.
>
> Kind regards,
> Calvin
>

Indeed. The point of a subclass is to create a *new type* of object, whi= ch 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 h= ave some that planes and trains don't. Modifying 'car' cannot a= ffect 'vehicle' or 'land_vehicle' without also affecting pl= anes 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 limitin= g it to only land-based travel).

Now in this case there seems to be some parallel hierarchy going on; ext= ending 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.)=A0 This is a lot trickier; you need to refacto= r it so that the code in 'vehicle' that instantiates 'driver= 9; can be overridden in the sub-classes, or something similar.

I find drawing on paper or a whitboard helps.

--bcaec554d43453fc4c04d7724cea--