Re: SOLVED! Decoupled Mutual Recursion Challenger

[gamache@rapnet.sanders.lockheed.com]

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;