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.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99f33f51845a7793 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-06 07:52:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!195.158.233.21!news1.ebone.net!news.ebone.net!lnewspeer00.lnd.ops.eu.uu.net!lnewspost00.lnd.ops.eu.uu.net!emea.uu.net!not-for-mail From: "David Crocker" Newsgroups: comp.lang.ada References: <3be27344$0$227$ed9e5944@reading.news.pipex.net> <3BE42900.7590E899@adaworks.com> <3be65f4c$0$237$ed9e5944@reading.news.pipex.net> Subject: Re: 'withing' problem Date: Tue, 6 Nov 2001 15:56:33 -0000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <3be80724$0$238$ed9e5944@reading.news.pipex.net> NNTP-Posting-Host: andrew.imsltd.com X-Trace: 1005061924 reading.news.pipex.net 238 194.202.27.87 X-Complaints-To: abuse@uk.uu.net Xref: archiver1.google.com comp.lang.ada:15917 Date: 2001-11-06T15:56:33+00:00 List-Id: Ted, I think you are saying that when a Patient object calls VisitDoctor, it should pass all relevant information (e.g. symptom and insurer) as parameters. In a simple case this may work well, but consider that, depending on the symptom and the particular doctor, the VisitDoctor procedure may require various additional items of information; how old the patient is, whether he smokes, whether he has a family history of particular diseases etc. These are all semi-static attributes of the patient. We would end up with a huge parameter list for VisitDoctor and much of the time, most of these parameters would not be needed. Surely it is much simpler to have VisitDoctor request these extra bits of information from the patent as and when they are required? This certainly doesn't constitute a complex control flow. Most OO developers would probably not even think of a call to a side-effect-free member function of an object as control flow at all. I agree that it is possible to use circular dependencies to create very complex and hard-to-understand programs, but *any* powerful programming feature can be used badly. Regarding the OO model where every object has its own threads, I don't think the model normally restricts each object to a single blocking thread, at least in respect of methods that don't change the object's state. Or, to put it another way, when an object sends a message to another object and is waiting for a reply, it can still receive and process a message from a third object before that reply is received, unless synchronisation mechanisms are used to prevent this. Regards David Crocker, Escher Technologies Ltd. www.eschertech.com "Ted Dennison" wrote in message news:ELCF7.13612$xS6.18271@www.newsranger.com... > In article <3be65f4c$0$237$ed9e5944@reading.news.pipex.net>, David Crocker > says... > > > >OK, so if you think cross-dependency reflects bad design when the > >implementation language is Ada, can you tell me how you would redesign the > >Doctor/Patent/Insurer example in > >http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html ? > > Make a new class called "symptom", which the doctor treats, and the patient has. > Make another new class called "insurer", which the doctor bills and the patient > has (and periodicly pays into). When a patient calls Visit_Doctor, they pass in > their symptom(s) and their insurer. > > Circular dependancies are just as bad an idea in OO control flows as they are in > traditional logic control flows. Think about what used to result back when > people made their own loops using all sorts of interrelated goto's. When > designing you should be looking for hierarchy and structure, not just any old > path through your objects that seems to work.