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:
- Using switch statements rather than polymorphism or interfaces.
- Classes that do too much, rather than being focused on a single goal.
What do you think? Do you have more examples?
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.
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();
}
}
That’s a Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) violation for sure!
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)
http://en.wikipedia.org/wiki/Ravioli_code 😀
Is this ravioli with or without sauce? Is the sauce the CLR?
So, excessive DEcoupling would be orzo? 🙂
<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]
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
PingBack from http://technote.thedeveloperside.com/?p=56
So, the time has come for the worst sin.
Just to recap – and so there is one post that lists them all…
PingBack from http://www.magerquark.de/blog/archive/374
PingBack from http://bagofbeans.tsangal.org/archives/203
PingBack from http://vibro-vagina.ru/sextovar/joy-100-220130.htm