Difference between coupling and cohesion
alex
coupling and good cohesion. They seem similar to me, what are the key
differences? How would you formally define each term?
Thanks,
Alex
Ian Davis
Cohesion is putting stuff that belongs together together. Creating "tight"
code. Coupling is creating dependencies between code. That is generally a
bad idea, if it can be avoided. The tighter the coupling the harder it is
to change one thing without having to worry about what else needs changing.
Cohesion is somewhat similar because there is an implication that if you've
put stuff that belongs together in a well design collection of cooperating
capabilities, you've decoupled it from the other stuff which it shouldn't
be related to. Good cohesion should lead to easy to understand. Loose
coupling should lead to easy to change. Both are necessary when developing
quality software.
Ian
dlp
> code. Coupling is creating dependencies between code. That is generally a
> bad idea, if it can be avoided. The tighter the coupling the harder it is
> to change one thing without having to worry about what else needs changing.
> Cohesion is somewhat similar because there is an implication that if you've
> put stuff that belongs together in a well design collection of cooperating
> capabilities, you've decoupled it from the other stuff which it shouldn't
> be related to. Good cohesion should lead to easy to understand. Loose
> coupling should lead to easy to change. Both are necessary when developing
> quality software.
Is high cohesion another word of loose coupling? It seems that the two
terms are very related together that I can't see any instance where
high cohesion actually produces tighter coupling.
It seems to me that the difference between the two is just a matter of
focus, increasing cohesion focuses on grouping of related items,
decoupling focuses on ungrouping / releasing dependencies between
items that are not related.
Also, (considering the difference in focus) will these definitions
work for both:
- cohesion: the degree to which members that are related to serve a
single purpose is grouped together.
- coupling: the degree to which a piece of code depends on another
piece of code.
dlp
definitions for cohesion and coupling are correct?
Caroline Kierstead
dlp <james....@gmail.com> wrote:
>> Cohesion is putting stuff that belongs together together. Creating "tight"
>> code. Coupling is creating dependencies between code. That is generally a
>> bad idea, if it can be avoided. The tighter the coupling the harder it is
>> to change one thing without having to worry about what else needs changing.
>> Cohesion is somewhat similar because there is an implication that if you've
>> put stuff that belongs together in a well design collection of cooperating
>> capabilities, you've decoupled it from the other stuff which it shouldn't
>> be related to. Good cohesion should lead to easy to understand. Loose
>> coupling should lead to easy to change. Both are necessary when developing
>> quality software.
>
>Is high cohesion another word of loose coupling? It seems that the two
>terms are very related together that I can't see any instance where
>high cohesion actually produces tighter coupling.
No, they're different concepts; however, they tend to be inversely related
to each other. So, something that has high cohesion tends to have loose
coupling.
>It seems to me that the difference between the two is just a matter of
>focus, increasing cohesion focuses on grouping of related items,
>decoupling focuses on ungrouping / releasing dependencies between
>items that are not related.
>
>Also, (considering the difference in focus) will these definitions
>work for both:
>- cohesion: the degree to which members that are related to serve a
>single purpose is grouped together.
>- coupling: the degree to which a piece of code depends on another
>piece of code.
Yes, that's a reasonable rough definition. I like the description shown at
the following site, plus it has pretty pictures that help showcase the meaning :)
http://www.waysys.com/ws_content_bl_pgssd_ch06.html
--
--
Caroline Kierstead, Undergraduate Operations Coordinator
David R. Cheriton School of Computer Science
University of Waterloo, DC3122 (519) 888-4567 x36226
Ian Davis
>> code. Coupling is creating dependencies between code. That is generally a
>> bad idea, if it can be avoided. The tighter the coupling the harder it is
>> to change one thing without having to worry about what else needs changing.
>> Cohesion is somewhat similar because there is an implication that if you've
>> put stuff that belongs together in a well design collection of cooperating
>> capabilities, you've decoupled it from the other stuff which it shouldn't
>> be related to. Good cohesion should lead to easy to understand. Loose
>> coupling should lead to easy to change. Both are necessary when developing
>> quality software.
>
>Is high cohesion another word of loose coupling? It seems that the two
>terms are very related together that I can't see any instance where
>high cohesion actually produces tighter coupling.
>
No.. you might have loose coupling and very poor (low) cohesion. You've
avoided needless coupling, but you've put your XML string encoding logic
in every place where an XML string needs to be printed..
You might have strong cohesion and way over the top coupling.. the XML string
encoding is in one place and so satisfies high cohesion. Instead of passing
in the string to be encoded, you are passing in copies of every object in the
system, together with an enum which says which object is to have a string
printed, and a second integer which says which string in that object needs to
be printed. (ie control coupling, stamp coupling, etc.)
>It seems to me that the difference between the two is just a matter of
>focus, increasing cohesion focuses on grouping of related items,
>decoupling focuses on ungrouping / releasing dependencies between
>items that are not related.
>
Yes it seems that way, but that is because you are presuming good design.
Good design does tend to focus on improving cohesion and reducing coupling,
just as good driving tends to focus on staying on the road and not killing
people. But staying on the road, and not killing people are actually two
separate concerns.
>Also, (considering the difference in focus) will these definitions
>work for both:
>- cohesion: the degree to which members that are related to serve a
>single purpose is grouped together.
>- coupling: the degree to which a piece of code depends on another
>piece of code.
Each is a separate definition. Your definition of cohesion needs to
be stronger.. It is the degree to which members that are related to serve
a single purpose are grouped together, but it is also the degree to which
other unrelated activities not serving that single purpose are kept separate.
It is putting together what belongs together, while also not cluttering
that logic up with other stuff that belongs elsewhere.
For example, in A7 you should have tried to separate out the logic to
handle the x, f and d flags. Using the strategy design pattern with
8 different classes to handle printing for all combinations of these flags
would not have resulted in good cohesion, but bad cohesion. Such an
approach would risk muddying the parts of the logic with the whole.
And yes, it would also risk poor coupling because the whole would need
to see stuff that each individual part had no interest in.
Ian
