Loose vs. Tight Coupling

[tlm]

I have been reading with great interest an exchange between tilly on one side and apotheon and adrianh on the other, on the subject of loosely coupled (aka modular) vs. tightly coupled systems. I thought this was too great a topic, and the arguments presented too well made, for it to be buried in an unrelated thread, so I thought I would turn my $0.02 into a root node, to call attention to this topic and to these comment nodes.

My experience agrees with both sides of this argument. I do scientific programming. The programs I and my colleagues write are intended to perform some analysis (number crunching, or simulations, etc.), and ultimately spit out answers. We are constantly pushing the performance envelope, because the person who gets the paper in Science or Nature is the one who was able to push that envelope the hardest to tackle problems that the rest of the field has not being able to tackle.

But scientific programming often also demands modularity and lose coupling, because every set of results prompts new questions that often make the programs that produced the answers obsolete. So we are in a constant tension between making our programs fast enough (which invariably means tight coupling) and modifiable enough (which means loose coupling).

Hence, we end up doing a lot of hybrid Perl+XS+C programming: Perl wrappers for rapid development and user interfaces, and C libraries for the time-critical core routines. And even the Perl stuff is not as modular is it could be, because it would be too slow. I have re-invented many wheels in pure Perl because the beautifully modular, exquisitely object-oriented stuff I could download from CPAN was simply too slow.

I close with the words of the inimitable Linda Richman: discuss.

Well, I guess that's two lies right there: it's only one word, and Linda Richman is famous only because she is eminently imitable... Oh, well. Too tired now to think of a more truthful ending.

[BrowserUk]

Mass production, which in software terms is really widespread reuse as in DBI or HTML::Parser, always benefits from loose coupling--externally.

But one of the greatest benefits of loose coupling in the external interface of a module, is that it allows the internals to be very tightly coupled whilst concealing the complexity of the implementation from the user.

Graphics Adapters were originally very tightly coupled to their processors. The graphics on the Atari and Amiga PCs that were so revolutionary in their time, used highly customised chipsets that worked in tight syncronisation with their cpus, and made the generalised, loose-coupled adapters in IBM compatible PCs look positively clunky by comparison. Now, the loose coupling in the latter shines, because it allows the like of Nvidea et al to produce internally highly tuned, complex and powerful cards with their own on-board, specialist processors, whilst maintaining loose compatibility with anything that talks to them via that same clunky interface defined way back when.

The problem with designing for loose coupling, as with most things, is where to draw the line. OO-doctrine will require you to use abstract interfaces within a module and between subcomponents of that module, as well as at the external interface. In many cases, that is a step too far. The overhead costs of loose coupling internally, can mean that the benefits of a well defined external interface are never truely realised, because the module is too slow for real world applications.

The trade-off when designing for loose-coupling is:

How likely is the subcomponent behind that interface to be reused in it's own right, rather than as a component of the larger system?

If the answer is "Not very likely", then it may well be better to eshew the loose coupling at that level, in order to realise the benefits, usually performance, to the overall system, derivable from tight coupling internal subcomponents.

[spurperl]

The looseness of coupling versus performance is one of the most common, and often the most difficult decisions I make in my job as a programmer.

I *love* modular designs - they feel right for me. I like it when I can reuse a module - so much time saved ! I like thinking modularly, it simplifies the process and allows to build complex programs easily.

However, modularity often comes at the price of degraded performance. It's a basic fact of life, tighter coupling improves performance because of lessening the cost in the interfaces.

The best solution to this problem, IMHO, is the common engineering trade-off. I tend to design modularly, then profile. Wherever the performance matters most (remember those 80/20 rules) I tighten the coupling.

[demerphq]

Code generation provides a way around some of these issues. A clever design can use loose coupling for development and maintenance and then generate tightly-coupled equivelent code when more efficient processing is required. For instance when processing large volumes of data method call overhead and the like can be inefficient, likewise dynamic control structures also can be inefficient, however both can be mechanically mapped to inline solutions. The resulting code isnt pretty at all but it is generally much faster than what it replaces.

[dragonchild]

Loose coupling is a tradeoff between higher design costs and lower maintenance costs. If you know you will be spending a lot of time in maintenance, then the higher design cost is amortized over the savings in maintenance. If, however, you won't be doing that much maintenance, then loose coupling is a waste of time.

In other words, if you can guarantee that maintenance will not be an issue, then couple tightly. But, personally, I've never been able to guarantee that. *shrugs*