[
Lists Home |
Date Index |
Thread Index
]
Hi.
I'll be reading the links Len sent out for a while now. Up to now my
practicing (and by practicing I mean semi-literate but personally useful)
definition for coupling was this:
Coupling is an interaction between components or applications.
How tightly coupled components are is determined by the extent to which
internal changes in one component require internal changes in the other.
By this definition, tight coupling tends to increase maintenance costs.
In my mind loose coupling is irrevocably associated with having good and
consistently used APIs.
In your example, neither pattern substantially changes coupling. Both
have different kinds of fragility.
Furthermore, a transform can move you from one form to another with no
loss of data. In systems where you're using the same data lots of
different ways, you end up with lots of end formats and automated ways to
reach those points (many website are that now).
The questions become "what formats allow you to capture the most
information" and "how do you transform and merge data held in those
formats". In this context, calling something a "best practice" carries
little information. Calling something "a practice that optimizes for X"
is closer to being useful.
I associate your first use of references:
<Lot id="1">
-- info about the lot --
</Lot>
<Picker id="John" isOnLot="1">
-- info about the picker --
</Picker>
With relational design, where one-to-many associations are modelled as
attributes on the many side. Familiarity to people well versed in
relational design is the strongest pro I can think of for it.
I associate your second use of references:
<Lot id="1">
-- info about the lot --
</Lot>
<Picker id="John">
-- info about the picker --
</Picker>
<Assignment picker="John" lot="1"/>
With topic maps and modelling associations with roles. Why not have:
<association type="isBeingPickedBy">
<participation type="picker" participant="John"/>
<participation type="lotBeingPicked" participant="1"/>
...
</association>
At the ellipses you can add all kind of meta data about the association.
Time started, time ended, picking rate, etc.
----------->Nathan
On Tue, 1 Feb 2005 07:35:09 -0500, Roger L. Costello <costello@mitre.org>
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"/>
>
> 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
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
--
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
Nathan Young
A: ncy1717
E: natyoung@cisco.com
|
