[
Lists Home |
Date Index |
Thread Index
]
Roger L. Costello wrote:
> Hi Folks,
>
> Again, many thanks for the excellent comments. I am working hard to
> assimilate all your comments, and will create a summary of all the
> discussion soon.
>
> One question that several people asked was, "What do you mean by coupling?"
> Below I have made an attempt at defining coupling. Do you agree with my
> definition? Is it complete, i.e., are there other factors that should be
> incorporated into a definition of coupling?
>
> Note that I have changed version #2 to this:
>
> <Lot id="1">
> -- info about the lot --
> </Lot>
> <Picker id="John">
> -- info about the picker --
> </Picker>
> <Assignment picker="John" lot="1"/>
>
> The Lot component just contains information about the Lot. And the Picker
> component just contains information about the Picker. The Assignment
> element connects the Lot and Picker. ["Assignment" is not really the
> correct name. Can someone think of a better name?]
>
> Okay, now for my definition of coupling:
>
> What is Coupling?
>
> Definition: There exists a coupling between two components if there exists a
> "dependency" between the components. The greater the dependency, the
> greater the coupling.
>
> An obvious dependency is physical dependency. In version #1 the Lot and the
> Picker are physically dependent (coupled) on each other:
>
> <Lot id="1">
> <Picker id="John">
> .
> </Picker>
> </Lot>
>
> The Picker is a child of Lot. The Lot is the parent of Picker. There
> exists a definite physical co-dependency between the Picker and Lot
> components.
>
> A more nebulous dependency is semantic dependency. In version #1 not only
> does there exist a physical dependency, but there also exists a semantic
> dependency. Namely, the Picker is located on the Lot.
>
> Now consider version #2:
>
> <Lot id="1">
> .
> </Lot>
> <Picker id="John">
> .
> </Picker>
> <Assignment picker="John" lot="1"/>
I would hate to have transform this... I would much rather have
something like this:
> <Lot id="1">
> .
<picker ref="John"/>
> </Lot>
> <Picker id="John">
> .
> </Picker>
Much easier to transform as you flow through the source(s) -- at least
for me. Of course you have a very simple situation above. One situation
in our CMS which is similar is assigning content pieces to regions in a
page or folder (when assigned to a folder it cascades down to its
pages). Content can be assigned to more than one page/folder so you
definitely would not want your scenario 1. But order matters -- for
example how would you structure something like:
<regions>
<region name="main">
<content ref="some-summary-piece"/>
<content ref="some-content-piece"/>
<content ref="some-callout"/>
<content ref="some-content-piece2"/>
</region>
<region name="nav">
<content ref="upcoming-events"/>
<content ref="recent-news"/>
</region>
</regions>
I can see how you could transform your scenario 2, but you have to
always 'look stuff up' and you would have to add more attributes when
the situation gets more complex rather than flow throw the source. In
other words, normalize it out as much as necessary, but keep the
hierarchy structured. Maybe this is why RDB oriented folk tend to find
XSL so difficult -- they normalize things out flatly rather than
hierarchically and find that presenting/transforming to different
views/sources so difficult.
best,
-Rob
> The Lot and Picker components are physically completely separate. There is
> no physical dependency. The Assignment element creates a semantic
> dependency between the Lot and Picker, by identifying that the Picker is on
> the Lot.
>
> So, in version #1 there exists both a physical and semantic dependency
> between the Picker and the Lot. In version #2 there exists only a semantic
> dependency. Thus, there is a stronger coupling between the Picker and Lot
> components in version #1. We say that there exists a tight coupling between
> the components in version #1. There exists a loose coupling between the
> components in version #2.
>
> Comments? /Roger
|
