From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: "Robert Martin" Subject: Re: Which wastes more time? (Was Re: Software landmines (loops)) Date: 1998/09/05 Message-ID: <6srh67$sj5$1@hirame.wwa.com>#1/1 X-Deja-AN: 388156622 References: <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <6sebjr$b69$1@nnrp1.dejanews.com> <6sff74$q0s@gurney.reilly.home> <6sh2j5$jnl$1@nnrp1.dejanews.com> <35EC2E5A.16DB6CB1@bigfoot-.com> <6sjc0a$1lk$3@news.indigo.ie> <35EFB09E.15412933@s054.aone.net.au> <35f2bd98.40599408@news.erols.com> <35F06A58.F968BDE1@s054.aone.net.au> <35f48276.90997557@news.erols.com> <35F0C3C9.D1E56FF3@s054.aone.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-05T00:00:00+00:00 List-Id: Loryn Jenkins wrote in message <35F0C3C9.D1E56FF3@s054.aone.net.au>... > >Anyway, whether or se/se is actually what Dijkstra was on about >(actually, I think he was on about something a little bigger than se/se; >se/se seems to me to be a principle that enabled him to get where he was >wanting to go), it seems useful to me. What Dijkstra was on about was a way to make assertions about a program. He wanted this so that he could evolve formal proofs of accuracy. He states three benefits of using four control sequence primitives. The first is a shrinking of the conceptual gap between the text of the program and its function. Second, was understandability, or to put it in his terms, an attempt to make the effort needed to understand a program proportional to the length of the program. The third is the most interesting from my point of view. He said that a program structured with the four primitives establishes a "coordinate system" between the text of the program and the execution of the program. (i.e. the execution state is strongly encoded by the execution position) This third benefit of Dijkstra's is essentially the argument that I have been making in this thread, that se/se keeps threads of control separate rather than collapsing them, thus providing place holders for future modifications. >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. 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. Meyer presents a model in which CAR_OWNER inherits from PERSON and uses CAR. And this is certainly a much better model. However, it is probably a mistake to take it much futher than that. Remember, this was an *example*, not a real program. We have no context to put this example in. It works for describing a poor use of multiple inheritance, but that's about it. So suggesting that Meyer's model is unacceptable is probably unsupportable. Better to say that Meyer's model has very little context, and that in certain contexts we would not want CAR_OWNER to derive from PERSON. 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). This motivation is a common theme running through Jacobson's work; indeed he contents that the final model will not look very much like the real world precisely because we want to make sure the model is future-proofed." Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan