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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-26 12:39:23 PST Path: nntp.gmd.de!xlink.net!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!news.mathworks.com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!sgigate.sgi.com!enews.sgi.com!decwrl!netcomsv!butch!rapnet.sanders.lockheed.com!rapnet.sanders.lockheed.com!gamache From: gamache@rapnet.sanders.lockheed.com Newsgroups: comp.lang.ada,comp.object Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger Date: 26 Oct 94 13:48:25 -500 Organization: Lockheed Sanders, Inc. Distribution: world Message-ID: <1994Oct26.134825.1@rapnet.sanders.lockheed.com> References: <1994Oct12.224944.25566@swlvx2.msd.ray.com> <1994Oct17.205244.17450@swlvx2.msd.ray.com> <1994Oct18.221751.15457@swlvx2.msd.ray.com> <38289r$79m@oahu.cs.ucla.edu> <1994Oct20.121408@di.epfl.ch> NNTP-Posting-Host: dune.sanders.lockheed.com Xref: nntp.gmd.de comp.lang.ada:16207 comp.object:16642 Date: 1994-10-26T13:48:25-05:00 List-Id: In article <1994Oct20.121408@di.epfl.ch>, Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes: > > As an analogy consider a wall as representing a programming problem > and a language as providing a way to get to the other side. What you > have seen is a lot of "ugly workarounds" to go through the wall. > I saw at least one suggestion to go over the wall and another to > go around the wall but both were refused. Why? because the goal > had ceased being "getting to the other side" but instead had become > "going through the wall". > > - Robb Nebbe > I've been reading this thread for awhile now and have finally organized my thoughts enough to respond. I chose to reply to the above to further amplify and clarify the issues on "Decoupled Mutual Recursion". It is not my intent to put words in Mr. Nebbe's mouth (err, should I say Newsreader?) and if I have mistaken his post, I apologize, most of the material here is reasonably standalone. However, looking at the various solutions posted I had an almost intrinistic dislike to the generics approach, but found the solutions "to go over the wall and another to go around the wall" acceptable. What is "Decoupled Mutual Recursion"? ------------------------------------- While I have experience with coupling, I had not previously heard of this term. Thinking about it, I ask the net the above question. Is this a real term in general usage? If so, I suggest abandoning it in favor of a more descriptive term. What type of coupling is being "decoupled" anyway? To use diagrams consistent with this thread, two classes my be seen to be coupled by relationship R1 as shown below: +----+ R1 +----+ | C1 |-----------------------| C2 | +----+ +----+ These classes are coupled. To me, decoupling would look like: +----+ +----+ | C1 | | C2 | +----+ +----+ Yet, that is not what is being proposed, so I think the use of decoupled causes more harm than good. Further, to accomplish useful work, coupling is generally acknowledged to be required. One of the classical examples used is that of the wires connecting the speakers to the receiver/amplifier of a stereo system. If they are "decoupled" (again, to me this is synonomous with the word I have seen more often in the literature, uncoupled) then no sound will result and the system will not accomplish useful work. How can the speakers be coupled to rest of the system? They can be 'hardwired' (as in soldered to the speaker terminals and the wire running out the back of the speaker) which would be a form of high or tight coupling. Or they can be made to be easily disconnected/reconnected as with RCA-type jacks, or screw mounts. This would be a lower form of coupling. Thus, the notion of coupling as SCALE is born: low medium high +--------------------------------------------------------------------+ | Coupling Scale | +--------------------------------------------------------------------+ data stamp control common content In software engineering, it has become widely accepted that low coupling (such as data coupling) is good, whereas high coupling (such as content coupling) is bad. If "decoupled mutual recursion" is moving on this scale, from where to where? I couldn't make this out from the proposed solution. In fact, this reasoning solidifies my initial opposition to it. To see why, let me review the definition of one of the types of coupling listed above. This definition is from Page-Jones, but similar definitions are available from a variety of authors, sometimes the name of the specific type of coupling is different, but the end result is almost the same. Two modules exhibit content (or pathological) coupling if one refers to the inside of the other in any way; for instance,... if one module refers to (or changes) data within another.... Such coupling makes nonsense of the concept of black-box modules.... Now I'm not saying that the above was the *intent* of the proposed solution; however, if I evaluate the type of coupling that the proposed solution *implements* (on the basis of xyz_Identity.Value being System.Address *and* the very existance of To_Pointer operation), I am forced to conclude that many modules *MAY* modify the data of one another ==> content coupling. A Solution ---------- Okay, if any is even still reading, I have some thoughts regarding what I believe to be a low-coupled solution to this problem. Using the following approach, the entire issue of 'recursion' with 'one of its own subclasses' is a non-issue. The solution is the same whether or not the relations are between Office--houses--employee or Manager--supervises--employee. I'd like to lay complete and total claim to the following solution, however, it has been widely recognized and published by various authors (which is certainly how I learned about it :). As I read the problem statement, my determination is that the primary issue is really one of entity analysis. That is, which relationships need to be traversable in a single direction and which need to be bi-directional? In this case, Manager_Supervises_Employee and Employee_Is_Supervised_By_Manager can be assumed to have been determined to be of need. Shlear/Mellor describe this process as the creation of a "Reduced Information Model", while Yourdon in "Modern Structured Analysis" (Chap 12 for anyone reading along at home...) describes the process as follows: After the first-cut ERD has been developed, the next step that you should carry out is that of attributing the data element in the system to the various object types.... The attribution process may provide one of three reasons for creating new object types: 1. You may discover data elements that can be attributed to some instances of an object, but not to others. 2. You may discover some data elements that are applicable to all instances of two different objects. 3. You may discover that some data elements describe relationships between other object types. Using the above, if I had: +--------+ Supervises +----------+ | Mgr |--------------| Employee | +--------+ +----------+ I would have by rule 2 above the need to create another object class. These objects are known as Associative Objects. Shlear/Mellor define as "an associative object arises when there is supplementary information associated with instance of a relationship". Yourdon states that associative objects "represent something that functions both as an object and a relationship". Given this the picture that *should* be offered for implementation is: +--------+ +----------+ | Mgr |--------------| Employee | +--------+ | +----------+ | | +-------------+ | Supervises | +-------------+ This notation easily scales to problems of the dimension alluded to in earlier posts. I can attest to their success on large/complex projects involving Ada. We have been using these techniques since the mid-80's. By the way, I should have stated this more clearly at the outset, the reason I didn't like the proposed solution was that we had tried such approaches with Ada83 and found out first-hand the inherent integration problems (i.e. been there, done that). However, we are just starting any type of effort with 9X. Which leads me to the long awaited conclusion. The above ERD is easily implementable (even in Ada83) in a variety of acceptable ways, all of which house shared relationship data in a standalone, no hashing tables required, low-coupled package. (Interested readers are referred to Shlear/Mellors first book for implementation strategies concerning 1-1, 1-m, or m-m relationships of this type) Summary ------- (Maybe I should have put this at the beginning?) Anyway, I felt: o the proposed approach is an attempt to package content-coupling as a feature rather than a liability. o the problem statement is not new or rare, nor does it have much to do with subclasses, rather it is a problem concerning associative objects. o existing techniques are available and in place for dealing with associative object implementations in a low-coupled fashion. While its certainly possible I've been misreading this thread, to get realigned I would need identification of what type of coupling one is "decoupling" and what type one is ending up with. ----------------------------------------------------------------------------- with the_usual_i_dont_speak_for_my_employer_disclaimer;