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

["Robert Martin" <rmartin@oma.com>]

Loryn Jenkins wrote in message <35F20C37.89A79442@s054.aone.net.au>...
>> >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?)
>>
>> With respect, I think you have our roles reversed.  Your position is the
>> rigid one, since you are insisting on there being only one solution to
this
>> problem.  I, on the other hand, am suggesting that there are
circumstances
>> where other models (such as Meyers) may be valid.
>
>Sorry. I used general person "you" here. "You" might like to read it as
>"one".

Ooops, I'm embarrassed.  I guess I'm just used to confrontational posts.
Something I'll have to get un-used to now that I have adjusted my filters.

>Therefore:
>
>> >As far as I'm concerned, this flouts basic classification theory. As far
>> >as I'm concerned, this is *wrong*. (How can one claim to be programming
>> >for reuse, as Meyer so eloquently points out as a fundamental goal, and
>> >model things so rigidly? So incorrectly?)
>
>> Writing a book is one of the hardest things a human can do.  It is harder
>> than writing software, believe me.  Writing a book of *significance* (for
>> which OOSC2 certainly qualifies) is even harder.
>
>Yes, I agree with this. So many points Bertrand makes are so valid. Thus
>the (minor) imperfections stand out even more.
>
>> So I am not going to
>> complain too loudly about an imperfect example.  I am more likely to
>> complain about his rather flippant criticism of Somerfield; which I think
>> detracts from the credibility of the work.
>
>Perhaps, perhaps not. It is clearly an example of inheritance "done
>wrong".

Agreed.

>
>> Be that as it may, the example in question is not incorrect as it stands.
>> It's just not correct in all, or even most, contexts.
>
>Hmm. True. (That I've already granted previously, I believe.)
>
>Perhaps you may agree with me if a took a little weaker position, and
>claim that Meyer would have been better off choosing an unambiguously
>correct example. (And provided evidence of the context that makes is
>unambiguously correct. After all, if he dropped the Somerfield
>criticism, he'd certainly have the page count for it.)

Yes, that makes sense.


>By the way, can you conceive of a situation in which it would be
>incorrect to model a role of some class using the Role Pattern? (Just
>wondering, because whenever I come across a situation like this, I
>reflexively reach for this 'tool'.)


Have you ever seen the game program "Sim Tower"?  This is one of those
interesting simulation programs.  You are the manager and architect of a
skyscraper.  You must put rooms, lobbies, elevators, restaraunts, condos,
etc, etc, into the building.  Simulated people are attracted to the building
by your amenities and they either buy condos or rent hotel rooms.  You
slowly grow the skyscraper, floor after floor, adding more and more
amenities while more and more people use your services.   The process of
growth is delicate.  If you over invest, or if you do not provide the right
ratio of amenities, or if you under spend on maintenance, people start to
move out, your income base crumbles, and you face a downward spiral.

Now, the simulated people come in many forms.  Lets consider two, the
breadwinners and the homemakers.  In the morning the breadwinners take the
elevators to the garage where they drive to work, whereas the homemakers use
the amenities of the skyscraper to buy groceries, etc. etc.

These are certainly two different roles.  However, in the context of the
simulation, the objects are born and die in that role.  Therefore it would
not be incorrect to model this with a PERSON base class and with BREADWINNER
and HOMEMAKER deriving from PERSON.  Indeed, since we have to deal with
thousands of these little objects, we will be strongly motivated to
eliminate the pointers and delegations that a ROLE relationship implies.