Share via

Seven Deadly Sin of Programing - #7 - Excessive coupling

  • Article

(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

  • Anonymous
    May 23, 2006
    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.  

  • Anonymous
    May 23, 2006
    The comment has been removed

  • Anonymous
    May 23, 2006
    That's a Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) violation for sure!

  • Anonymous
    May 23, 2006
    The comment has been removed

  • Anonymous
    May 24, 2006
    http://en.wikipedia.org/wiki/Ravioli_code  :D

  • Anonymous
    May 24, 2006
    Is this ravioli with or without sauce?  Is the sauce the CLR?

    So, excessive DEcoupling would be orzo? :-)

  • Anonymous
    May 24, 2006
    <a href="http://www.pula-verde-prostituoitu.lollo6.com">svenske">http://www.pula-verde-prostituoitu.lollo6.com">svenske fitter rinta</a>           http://www.pula-verde-prostituoitu.lollo6.com         [URL=http://www.pula-verde-prostituoitu.lollo6.com]gratissex vagina resimleri[/URL]

  • Anonymous
    May 25, 2006
    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


  • Anonymous
    July 24, 2006
    PingBack from http://technote.thedeveloperside.com/?p=56

  • Anonymous
    August 04, 2006
    So, the time has come for the worst sin.
    Just to recap - and so there is one post that lists them all...

  • Anonymous
    August 05, 2006
    PingBack from http://www.magerquark.de/blog/archive/374

  • Anonymous
    October 10, 2006
    PingBack from http://bagofbeans.tsangal.org/archives/203

  • Anonymous
    May 25, 2009
    The comment has been removed