Post by dlpCohesion 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.. 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.)
Post by dlpIt 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.
Post by dlpAlso, (considering the difference in focus) will these definitions
- 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