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?

Comments (13)

  1. Peter Ritchie says:

    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.  

  2. Here’s coupling for you:

    How about a class that knows tooooooo much

    class KnowItAll


     public void Foo(ContainsALot x)





  3. Peter Ritchie says:

    That’s a Law of Demeter ( violation for sure!

  4. Bjorn Reppen says:

    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)

  5. Peter Ritchie says:

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

    So, excessive DEcoupling would be orzo? 🙂

  6. Padu says:

    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.



  7. So, the time has come for the worst sin.

    Just to recap – and so there is one post that lists them all…

Skip to main content