[QUANTITY] Inheritance vs Aggregation

[Martin Hill]

David Berry wrote:

> The benefit of having a general purpose Quantity class which is an
> aggregation of a standard set of optional components, is that you can
> produce a single programming interface to handle all sorts of Quantity,
> rather than having to produce different interfaces for every individual
> subclass of Quantity. This is much easier to use, and to maintain, than a
> complex inheritance hierarchy. I think this is commonly being recognised
> in the OO community these days - see for instance Joshua Bloch's book
> "Effective Java" item 14 (titled "Favo[u]r composition over inheritance").

This is a bit computer sciency, but:

While it is easier to maintain class implementations as aggregations 
rather than subclasses, if that is all we do we lose polymorphism and 
extension, two Great Things in OO.

On the Quantity discussion we're looking at using polymorphism, so that 
we can use Quantity subtypes in all kinds of situations. Or else we're 
talking about making the [Quantity] type suitable for everything, and 
that is Just Bad (I'll dig out some references and a rant or two if this 
is not clear!).

So the usual process now seems to be to build extensions into 
interfaces, and the implementations (classes) of these interfaces may 
well be aggregates. I tend to think of 'type' as either - as something 
declaring and using a class/interface cannot tell the difference between 
them.

This means we can quite happily declare we have a [Quantity] and a 
generalisation [QuantityWithError] that *is a* Quantity and *has a* 
Error, through the interface tree.  If you make a [Flux] subtype of 
[Quantity], your [FluxWithError] has to subtype [Flux] and 
[QuantityWithError].  Which might be a good thing or not - I still 
haven't got a grip on what Quantity is/is for and how Real Things relate 
to it...

Cheers,

Martin

-- 
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org