Feeds

Coupling and the power of accidental relationships

Emergent Design: break point

  • alert
  • submit to reddit

The smart choice: opportunity from uncertainty

Book extract, part three In the third extract from his book, Emergent Design: The Evolutionary Nature of Professional Software Development published by Addison Wesley, Scott Bain tackles the complex issue of coupling, and looks at how unnecessary complexity can be injected through accidental or bad coupling.

Coupling is a general term that describes the situation where one part of a system affects another part of the system in some way. Often, in object orientation, we are talking about two classes - classes are coupled to the other if a change in the second class will cause a change (or a need for a change) in the first. Coupling is usually spoken of in terms of it being a problem, but in fact coupling is not bad in all cases.

In fact, some coupling is absolutely necessary, since a system with no coupling would not be a system at all. Coupling, in the good sense, is how individual objects are combined to create the overall system. We do not want coupling that:

  • We did not intend
  • We did intend, but we do not actually need

Intentional coupling versus accidental coupling

Bad coupling is usually termed tight coupling. Logical, necessary, helpful coupling is called loose coupling. Loose coupling is ideal; tight coupling is to be avoided.

I am not wild about these terms, frankly. For one thing, they do not stick in my mind, and I always forget whether loose or tight is the bad one. They both sound bad, in a way loose things fall apart and tight things are hard to take apart and change.

My point is that part of what we are doing in promoting software development as a profession is getting terms like this more clearly defined, and to make sure they inform what we do.

To me, good coupling is coupling I (or you) put into the system on purpose, to achieve an end or solve a problem. The coupling that seems to "get me" is the coupling that I did not realize I had because it crept into the system without any intent on my part.

So, I use the terms "intentional" for good coupling and "accidental" for bad. It is not difficult to remember that accidental is bad - just think of a car wreck.

Coupling can occur at any level, from the code within a method to the architecture of the system overall. It can even occur in your driveway, as I shall explain.

Driveway coupling

I bought a new car a few years ago.

The next morning I went out to my car, got in, and started it. Once it was running, I tried to put it into reverse gear, but it would not go. The lever that selects from park, neutral, drive, and reverse would not move from park to reverse.

I was disappointed, and I called the dealer to explain the problem I was having. "Ah, yes, that always happens," he said. This was not what I wanted to hear. I had selected a car model that routinely broke its transmission? That was not what he meant. "People are always confused about this model... and we always forget to tell them for some reason. To put that car into gear, you need to put your foot on the brake."

Okay. So it would not have gone into drive or neutral either, since my foot was not depressing the brake pedal. I did not know that because I was not trying to go into anything but reverse (this is one reason beta testing is so difficult to get right). I was on a cell phone, so I tried it while the dealer was still on, and it worked.

"We sometimes just put our foot on the brake naturally when we start the car, so sometimes people do not run into this for a few days," he went on, "but invariably someone will call, within the first week, and report a failed transmission." "Why did they engineer it this way?" I asked. The designer in me was curious.

"It is to make sure your foot is not on the gas. People use their same foot for the gas and the brake, so if the foot is on the brake, it is not on the gas." he explained. That seemed to make sense.

But later I began to think. Why didn't they just hook up a sensor up to the gas pedal? I may or may not put my foot on the brake when I go into gear, but I certainly will not be accelerating at that point. In fact, that was the concern - that I not put the car into gear while revving the engine.

Securing Web Applications Made Simple and Scalable

Next page: Types of coupling

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.