Skip to content.

Manageability

Sections
Personal tools
You are here: Home » blog » archive » Categories of Loose Coupling

Categories of Loose Coupling

20021125055534

I had a very thought provoking conversation with Doug Kaye. This got me thinking about refining my thoughts about Loose Coupling.  In addition to my blog, there had been other blogs written in response to the Doug Kaye's original posting.

Loosely Coupled Frameworks enable tightly aligned business integraton provides a definition. "Loosely coupled frameworks allow individual nodes in a distributed system to change without affecting or requiring change in any other part of the system.".  Loose Coupling is defined in terms of why its needed.

Shades of loose coupling points out correctly that loose coupling or rather coupling is a matter of degree. "Instead, there are an infinite number of degrees, ranging from not-very-tight-coupling all the way to almost-completely-decoupled.".  It's recognized here that Loose Coupling is a kind of measure, however, I've got to disagree with the infinite number of degrees thought.

I have discovered actually 3 categories that support system change, however its not clear to me whether they are categories of Loose Coupling.  These are:

I. Introducing an Intermediary

II. Late Binding

III. Separation of Concerns

Doesn't this look a bit too familiar? The GOF (i.e. Design Patterns) book has a categorization of Design Patterns, that is there's Structural, Creational and Behavioral Design Patterns.  In fact, the motivation of many design patterns, (actually I'm not sure if its all of them) is to support some kind of change.  It's quite similar, and could prove extremely useful, since its quite clear Web Services are different from an OO programming language where the GOF book was applied.

One example that comes to mind is the REST argument, its of category III above. Communication from one party to another consists of a sentence with a verb and a noun. First of all there needs to be an agreement on semantics.  However, we can standardize on the semantics on the verb part, and therefore allow certain classes of communications to be possible without prior agreement between the parties.  It may seem that its pushing the problem down to another level, however I would argue that there are certain classes of communication that do not require full knowledge of the complete sentence.  This can be phrased as a design pattern, however its seems directly applicable to Web Services, actually I've heard hit referred to as an Architectural Style.

Speaking of Architectural Styles, there's the Adaptive Object Model (AOM), which actually is of category II above.  AOMs are Self Describing or Reflective.  In other words, a system where you have access to the meta level that is the definition of objects is more adaptable to change than one that has this information only in implicitly.  Systems that have structure defined by prior agreement tend to have the definitions defined on paper, however they not necessarily be a reflective system. That is, explicit meta-level allows the discovery of definition when its needed or as late as possible.

Created by admin
Last modified 2003-07-30 04:14 PM
visitors
reading
 
 

Powered by Plone

This site conforms to the following standards: