So when I first started this weblog, I called it “Loosely Coupled”, which probably means nothing to people outside the software industry. Since then I’ve vamped the title, but I the term still interests me. I forget how I found this article on Friday, but it’s a wonderul introduction to what the term means and how it applies to hardware, software and business in general. “Loosely Coupled: A Term Worth Understanding” defines loosely coupled as
“… loosely coupled is an attribute of systems, referring to an approach to designing interfaces across modules to reduce the interdependencies across modules or components – in particular, reducing the risk that changes within one module will create unanticipated changes within other modules. This approach specifically seeks to increase flexibility in adding modules, replacing modules and changing operations within individual modules.”
John focuses mainly on business practices in his article, while I find myself drawn more toward exploring loose coupling within software applications. Much like a writer of books or songs spends the majority of his or her time searching for that perfect word or rhyme, software developers spend inordinate amounts of time trying to reduce complex business functions into abstract and manageable (but useful) software functions or objects… and then spend the rest of their time trying to tie them all back together into a useful application. I think that loose coupling is the idea that when you’re designing your abstract and manageable functions & objects, you design them in such a way that getting them to work together is as easy as putting together a couple of Lego pieces. Implicitly then, you should be able to swap out a Lego piece for a different colored or shaped piece, as long both pieces share a common interface. Here’s a real world example:
I’m finishing up work on a ASP/.NET project that included commerce capabilities. The credit card charge and credit functions would be taken care of by a product that could only be interfaced using the HTTP POST mechanism and which returned it’s results not as XML (why not!!!?) but as HTML with hidden form elements (who thought this would be a good idea by the way?). A couple years ago (because of my knowledge, although the technology available was a hinderance as well) I would have hardcoded the ASP app to make an HTTP POST call to this app and then would have used a regular expression to parse and display the results. This results in a very tightly coupled design. If for some reason the credit card merchant came out with new software that returned an XML stream or if we decided on using a new credit card merchant, we would have to tinker directly with the ASP code, re-test that code, and deploy that new code to the n servers this project required. Note that this may have been (and still might be) the *fastest* (as far as execution time) method of fulfilling the requirements. A loosely coupled implementation (which I chose to use) would build a layer on top of the credit card merchant software, abstracting the web application built in ASP from having to know the details of the hidden form fields returned in the HTML generated by an HTTP post. I wrote two modules: a) a module that interfaced directly with the credit card merchant software, posting and retrieving information from the software, and b) a web service with an immutable interface (ie: the ASP web application with always be able to depend on the interface being the same, no matter what credit card merchant we use) that uses the aforementioned module to instantiate the credit card merchant application. While this might seem more complex (and it is), it’s also extensible (ie: wanna add some logging to the credit card charge/credit process? wanna cache results? wanna cluster the application? great! As long as the interface stays the same, you can could swap out the C# web service for a Java web service (or Perl… or ColdFusion). You could begin logging the transactions to a database. You could write some type of caching mechanism to remember credit card details, *all without modifying your core ASP web application code*.
I mentioned in my example that doing a direct HTTP post to the merchant software *might* be the fastest in terms of execution time. Going back to John’s article, it’s interesting to note that a loosely coupled system
“…creates a safe harbor for experimentation within the module. Greater ability to experiment enhances the ability to learn. New approaches can be tried more frequently and participants can learn which approaches yield higher performance within each module. As these successful experiments yield better results, the performance of individual modules tends to improve at a faster rate. The cumulative effect of this performance improvement across an entire loosely coupled system can be significant.”
Couple books mentioned in the article that might be worth checking out:
Design Rules – Vol. 1 : The Power of Modularity by Carliss Y. Baldwin, Kim B. Clark
Out of the Box: Strategies for Achieving Profits Today & Growth Tomorrow Through Web Services by John Hagel
The Component-Based Business: Plug and Play by Richard Veryard
Thoughts?