Re^6: Loose coupling (was Random quotes ...)

I still disagree. In real world cases tightly integrated designs have often been viable a decade or more before modularized designs came to market.

You seem to be implying (and please correct me if I'm wrong ;-) that loosely coupled systems are necessarily slower to market and/or perform significantly worse than tightly coupled solutions?

If so, I'm not entirely convinced. When I see tightly coupled software being produced it's normally a combination of one or more of:

Developers not having the necessary knowledge of ways to create software in a loosely coupled manner (e.g. not knowing about techniques like dependency injection.)
Not having appropriate tools to make the development of loosely coupled software simple (e.g. a language like Perl or Java offers more features that help with loose coupling than a language like C or COBOL.)
Not having experience of software development practices that encourage loosely coupled software (e.g. using TDD.)

Sure - there are some instances where a tightly coupled system has been deliberately chosen due to some constraint - but they seem rare in my experience. More often they're done first because that's the only way the developers know how to create software.

Comment on Re^6: Loose coupling (was Random quotes ...)

Replies are listed 'Best First'.
Re^7: Loose coupling (was Random quotes ...) by tilly (Archbishop) on May 02, 2005 at 01:37 UTC
I am not implying that. I am implying that maintaining loose coupling necessarily keeps you from being able to find certain kinds of optimizations, and that means that the top possible performance (tight memory, etc) can be hit by a tightly integrated application. If performance is a significant constraint (mini computers in the 70's, GUI interfaces on PC hardware in the 80's, PDAs in the 90s) then tightly coupled systems may be viable several years before loosely coupled ones are. (As a practical matter, most attempts to write a tightly coupled system will result in something slower than a loosely coupled system could have been. This is certainly a strategy that one would only try with very good reason.) This applies to a small minority of software, and applies to virtually none in the Perl world. Places where I might expect to see this happen today include extremely high-volume servers (eg Google), very constrained systems (eg many embedded projects), and computationally intensive products (some games). None of those are good candidates for Perl because Perl is relatively big and slow.	[reply]
Re^8: Loose coupling (was Random quotes ...) by adrianh (Chancellor) on May 02, 2005 at 12:09 UTC
I am not implying that. My bad. Then we agree :-) As a practical matter, most attempts to write a tightly coupled system will result in something slower than a loosely coupled system could have been. This is certainly a strategy that one would only try with very good reason. Yup. I think the point many people miss is that loosely coupled code/design doesn't necessarily lead to a hideously inefficient implementation. Even a naive loosely coupled implementation is not necessarily inefficient. Take into account the fact that compilers have got jolly clever over the years and picking a tightly coupled solution without a very good reason is foolish in the extreme.	[reply]