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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/29 Message-ID: <33660F4B.1B45@sprintmail.com>#1/1 X-Deja-AN: 238169494 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> <5jfukp$lda@top.mitre.org> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Matthew Heaney wrote: > I'm talking about just a pair of abstract data types that are intimately > related. But I sense that you and the other posters are talking about > large packages (say, a subprogram library such as binding). "Co-encapsulation," as I like to call it, has a cost: Loss of abstraction. Because both types have visibility to each other's private features, there is no way to enforce each to adhere to the discipline of only calling the other's public interface. This affects understandability: Readers must understand what both types are doing, internally, before they can be sure they know what either type is doing. Of course, if it's just "a pair of abstract data types that are intimately related", and that's all there is to it, then the cost of abstraction-loss is relatively small, so co-encapsulation may be a reasonable option. But what if that's not all there is to it? Then the transitivity problem rears its ugly head: If class A is "intimately related" to class B, and class B is "intimately related" to class C, you may be forced to co-encapsulate A, B, and C, despite the fact that you did not envision any "intimate relationship" between A and C in your original software design. What if you've used an object-oriented analysis and design method, such as OMT or UML, to develop a model of your application domain comprised of a lot of classes linked together by a lot of binary associations? *Any* binary association might be construed as an "intimate relationship" between the two clases involved. But each class may be involved in several associations. And if your model is complete, I believe it should form a single contiguous graph of classes linked by associations, with no isolated islands. Under these circumstances, if you allow the transitivity effect to proceed unchecked, it can spread like a virus to infect your entire application. Robert Dewar hits on this problem: Robert Dewar wrote: > > ... -- it is really a natural > consequence of any domain in which recursion is an important idiom. > > For example, if we have a compiler with separate units to handle if statements > and loop statements, it is natural for if's to have loops and loops to have > if's. Surely you don't think this means that we have to put loops and if's > in the same unit -- because if you do you are syaing the whole compiler must > be one unit! Here, I take "recursion" to mean "recursive data structures," where an object of one type may contain references to objects of another type, and vice versa. I would go one step further: The transitivity problem doesn't just affect applications that involve this kind of recursion. *Any* binary association, conceived of during object-oriented analysis, is potentially vulnerable when you get to the design stage, and have to decide whether the association needs to be traversible in one direction, or the other, or both. A mutually-recursive data structure is just one way of implementing bidirectional traversals, but it's not the only way. It was this transitivity problem that prompted me to kick off that long thread a couple of years ago, and it was the seriousness of this problem, as I saw it, that prompted me to pursue that thread for so long. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------