Re: Which wastes more time? (Was Re: Software landmines (loops))

[Loryn Jenkins <loryn@s054.aone.net.au>]

> >The second (counter) example is inspired by OOSCII, Chapter 12. In it,
> >if I recall correctly, Bertrand has class CAR_OWNER inherit from class
> >PERSON. (He offers this as an example of 'how to do inheritance well'.)
> >He implies that this is acceptable modelling for an application. Now,
> >while I can imagine this working for some applications, I can't believe
> >it is acceptable.
> >
> >I can't believe it is acceptable because it does not model our concept
> >of reality. Instead, it should have been modelled as a role of a person.
> >That is CAR_OWNER inherits from PERSON_ROLE, and PERSON_ROLE has an
> >attribute of type PERSON.
> >
> >Modelling it this way would have future-proofed the application against
> >handling situations when people in the application became car owners and
> >then stopped being car owners. Even if it was valid for an application,
> >the second is preferable, because I don't have to scratch my head,
> >wondering about the possible implications.
> 
> I found the example in Chapter 24.

Sorry, it is in Chapter 24.

> Meyer is complaining about Ian
> Somerfield's description of multiple inheritance in his "Software
> Engineering" textbook.  (side note: I find these unkind attacks by Meyer all
> too frequent.  He could have just said: "I disagree with Somerfield" and
> left it at that.)  In any case Somerfields model had CAR_OWNER multiply
> inheriting from CAR and PERSON. Certainly, in light of what we know today,
> this would not be an acceptable model.

I think classification theory has been around for an awful long time
(didn't Plato initiate study into this field?); surely you can't excuse
the Ian Somerfield because he wrote a mere few years ago. (I think)
Meyer is quite correct in pointing this out to be a ridiculous model. It
certainly isn't a good example.

>   Meyer presents a model in which
> CAR_OWNER inherits from PERSON and uses CAR.  And this is certainly a much
> better model.

Agreed. But it still flouts basic classification theory.

I find this test to be a very useful in finding whether a (sub-type)
inheritance relationship should hold:

Is the child class a type of the parent class, and will it be for the
whole of its existence? And, is the parent class a supertype of the
child class, and will it be for the whole of its existence?

That is, in this example:
(1) Is a CAR_OWNER a PERSON, and will it be for the whole of its
existence?
(A1) Yes.

(2) Is a PERSON a CAR_OWNER, and will it be for the whole of its
existence?
(A2) No. Any PERSON can buy and sell cars, moving its status from car
owner to not multiple times during their life.

As far as I'm concerned, this flouts basic classification theory. As far
as I'm concerned, this is *wrong*. (How can you claim to be programming
for reuse, as Meyer so eloquently points out as a fundamental goal, and
model things so rigidly? So incorrectly?)

However, I can easily understand why Bertrand modelled things like so:
simplicity. He was simply trying to make a point about the difference
between inheritance and clientship. In hindsight, I think he may have
been better off choosing a simple example that works well in all
contexts.

> However, I strongly sympathize with motivation.  I agree that we should give
> thought to 'future proofing' our application structures (although I don't
> think that a simple reliance on real world structure actually accomplishes
> that goal).

The Role Pattern (very similar to Gamma et al's State Pattern) just
described here doesn't necessarily model 'the real world'. I think it
does model our 'concept of the world', according to a certain
classification theory.

Loryn Jenkins