Data Model for Quantity v0.5 - inheritance vs aggregation

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Mon May 10 13:10:02 PDT 2004


On Monday 10 May 2004 08:50, Brian Thomas wrote:
> 	There is no fixed inheritance tree. The proper term is
> "realization". Each
> 	interface has an established realization relationship between
> themselves.
> 	*But this is NOT the same as inheritance*. You are not forced
> into creating
> 	a class hierarchy which mirrors the interface at all. I happen
> to think its easier
> 	if you do, but hey, thats an *option*. I regret that I lost the
> argument with the
> 	other editors to change the language surrounding figure 1 to
> reflect that we
> 	are proscribing "realization" and not "inheritance"
> relationships, but that is
> 	what is intended.

FYI - realization is the relationship between an interface and the class that 
implements it. One interface still inherits from another. the Q document does 
specify an inheritance relationship.

So, the above is just plain wrong and I have argued the point before.

As for the point about implementors being free, that is true in principle but 
bogus in practice. If you have (trying to not be too java-esque here and it 
doesn't apply just to java anyway):

interface Frame
interface CoreQ extends Frame
interface StdQ extends CoreQ

then when I write my implementation and I have

class MyStdQ realizes StdQ // java: implements
{
    // must have all methods from Frame, Core, and Std
}

Sure, I could write

class MyFrame realizes Frame 
{
   // Frame methods
}

followed by

class MyCoreQ realizes CoreQ inherits from MyFrame
{
     // add CoreQ methods here
}

OR

class MyCoreQ realizes CoreQ
{
    // add Frame and CoreQ methods here
}

BUT the latter would be clearly stupid because I would have implemented frame
methods twice. So, one clearly has to write monolithic classes or use the 
specified inheritance tree.

The interfaces in the Q doc specify a type of relationship that the 
implementations are more or less forced to follow. 

Interfaces are meant to be declarative ("I have these methods!") first and can 
- if it is valuable - have an interface heirarchy. Here we have both and it 
is an extra burden and limitation on implementors.

-- 
Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)



More information about the dm mailing list