Welcome to MSDN Blogs Sign in | Join | Help

Seven Deadly Sin of Programing - #7 - Excessive coupling

(these will be in reverse order...)

#7 - Excessive Coupling

We start out with a simple one.

Coupling is obviously a necessary evil. The Console class, for example, wouldn't be able to send text through Win32 without being coupled to Win32.

Given that, less coupling is nearly always better that more coupling. A few cases that I see:

  1. Using switch statements rather than polymorphism or interfaces.
  2. Classes that do too much, rather than being focused on a single goal.

What do you think? Do you have more examples?

Published Tuesday, May 23, 2006 8:43 AM by ericgu
Filed under: ,

Comments

Tuesday, May 23, 2006 12:49 PM by Peter Ritchie

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

That's certainly on my top 7 (which I'm calling the 7 bad habits)  Mine is higher (lower #) on my list based on bugs that I've fixed with legacy code.  I.e. excessive coupling is # 5 of my list of reasons/causes of a defect, or negatively limits the fix for a defect, of defects I've had to research/fix.  
Tuesday, May 23, 2006 1:15 PM by Erno de Weerd

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

Here's coupling for you:
How about a class that knows tooooooo much
class KnowItAll
{
 public void Foo(ContainsALot x)
 {
   x.y.z.a.b.c.d.MakeItSo();
 }
}
Tuesday, May 23, 2006 1:21 PM by Peter Ritchie

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

That's a Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) violation for sure!
Tuesday, May 23, 2006 5:48 PM by Bjorn Reppen

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

My #7b: Excessive decoupling.  Can lead to code that is extremely hard to read/follow/debug/maintain.  In a system with coupling the compiler can help tell you at compile-time when something isn't right.  In an excessively decoupled system errors often won't show up until run-time.  

Also, excessively decoupled components often doesn't communicate well, the developers have wasted time trying to get everything decoupled, and the resulting program will most likely run slower.

See also: Custom UI Application Block (CAB)
Wednesday, May 24, 2006 12:16 PM by DeanG

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

Wednesday, May 24, 2006 12:26 PM by Peter Ritchie

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

Is this ravioli with or without sauce?  Is the sauce the CLR?

So, excessive DEcoupling would be orzo? :-)
Thursday, May 25, 2006 2:54 AM by Carita

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

Thursday, May 25, 2006 4:10 PM by Padu

# re: Seven Deadly Sin of Programing - #7 - Excessive coupling

I just finished a graduate class on OOD, and one of our tasks was to digest a paper on coupling and cohesion (Object Coupling and Object Cohesion, chapter 7 of Essays on Object-Oriented Software
Engineering, Vol. 1, Berard, Prentice-Hall, 1993, pp. 72-86) and that was very interesting.
Sometimes on the heat of coding, you break the "design for an interface, not for an implementation" and endup doing things to make you class work, instead of carefully thinking what your class abstraction represents.

When you pause and actually try to decrease coupling and increase cohesion, your model gets much cleaner.

Cheers

Padu


# Technical Related Notes » Blog Archive » links for 2006-07-19

Friday, August 04, 2006 12:45 PM by Eric Gunnerson's C# Compendium

# Seven deadly sins of programming - Sin #1

So, the time has come for the worst sin.
Just to recap - and so there is one post that lists them all...
Saturday, August 05, 2006 5:17 PM by Magerquark.de » “Seven deadly sins of programming”

# Magerquark.de » “Seven deadly sins of programming”

# My Bag of Beans » Blog Archive » Seven deadly sins of programming

# ?????????????????????????? ??Twin pleasures?? ????????????????, ????????????, ???????????????? ???????????? ????????????

New Comments to this post are disabled
 
Page view tracker