Channels ▼
RSS

Design

Insidious Tight Coupling

Source Code Accompanies This Article. Download It Now.


Bil has written three books on multithreaded programming, along with the GNU Emacs Lisp manual and numerous articles. He is currently a professor at Tufts University and can be contacted at bil@lambdacs.com.


Coupling is a rough measure of how much one software module relies on another. In particular, "loose coupling" refers to a module that uses only a published interface to another module. Tight coupling, on the other hand, depends on internal details.

Tight coupling is a bad thing because it means that every time someone decides to change the implementation of his or her module, every tightly coupled module might have to be changed, too. For instance, in Example 1(a) a loosely coupled module will only use getAge(). Should a module "cheat" and access the age instance variable directly, then when Example 1(b) is distributed, the cheating module will no longer even compile.

<b>(a)</b>

class Person { 
   int age;
   public int getAge() {return age;}
}

<b>(b) </b>

class Person { 
   int birthYear;
   public int getAge() {return thisYear - birthYear;}
}

Example 1: (a) Tight coupling; (b) a failure waiting to happen.

Loose Is Better, Always

What you often hear about is the necessity to couple more tightly "for performance reasons." Indeed, it is not difficult to come up with examples of where tight coupling lets naïve compilers produce significantly better code—but you shouldn't use naïve compilers for production code.

The one good thing about this kind of tight coupling is that the compiler prevents you from distributing nonworking code by accident. Which brings us to insidious tight coupling (ITC).

ITC is the situation where one module depends on another module having some special state, or set of string literals, but where the compiler doesn't know. In this case, it is easy to make changes to one module and miss another module that was making assumptions about the first.

An example would be where you know that students are to be entered into a list in grade-point order. If another module relied upon this, then it would fail should the students be entered in a different order. The appropriate way to deal with this situation is to make your code reflect the requirements you put upon it. In this case, you would subclass List with a class SortedList, which would throw an exception if someone tried to insert a student out of order.

The most common example of ITC is when two modules need to use the same string literal. Within a single language project, this issue is resolved through the use of canonical objects and constants. But the trouble starts when those modules are in different languages. There's no compiler to tell you when you misspell a variable name, or that you only changed six of the seven places a literal was used. Moreover, because the typical use of these strings is for table lookups (request.getParameter("firstName"), for example), a null value might be a legal value, making it much more difficult to find the problem. (Often times, the bug is never noticed and the program simply spits out incorrect data.)

This is ITC at its worst. And where do you typically see many languages coming together? Web apps!

For instance, consider:

  • You decide to write the logic in Java.
  • 2, 3. You're targeting browsers, so you need HTML and JavaScript.
  • You'll certainly use CSS.
  • Ajax is popular, which means XML or JASON (or both!)
  • You're running Apache, so you'll need an XML DTD for configuration files.
  • 7, 8. What good is a web site if you can't make objects persistent? So you'll need SQL/HQL. Maybe you want Hibernate? Those config files count.
  • 9, 10. Finally, you'll want to write out a pretty page and you'll need JSP+JSF or something similar.
  • HTTP! I forgot HTTP.

That's 11 languages for an elementary application. This is insane. What the heck are we doing? Well, we're letting tools control our lives. We are designing our applications so that they'll fit neatly into Ruby or Tapestry or J2EE. We have all these fancy tools that work for one aspect of creating a web application, then leave us to muddle through the rest. Tools are supposed to serve us. We are supposed to decide what we want, then find the tools that let us do it. We can write software to do anything. Why don't we write software to build entire web applications?


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video