Any standalone software
monolithic entity doesn't require internal boundaries to define within it,
rather when one break things down using divide and conquer problem solving approach;
we end up with chunks of entities that are left with inevitability to cooperate
smartly among themselves and hence the need for collaboration emerges. Collaboration
of methods / entities / objects / modules / packages etc. are all guided by set
of higher level principles like coupling and cohesion. The other day I quizzed my fellow worker about,
how to avoid coupling? He immediately quipped back with array of reasons, but
surprisingly failed to explain the term. That led to the genesis of this post.
Coupling: It can be described as any form of linkage or
connection or medium between two entities. Now the intensity and scope of this
linkage is what leads us to draw out degree of coupling, into two categories as
low / weak / loose and high / strong / tight. Typically two (or multiple)
methods / objects / modules link through a common data structure. Now to refine
the type of coupling, we evaluate them on the extent this structure is exploited
like, how far the data structure is propagated, how big / small & relevant /
irrelevant passed data structure is? & how the receiving data structure is
utilized inside? etc.
Impacts of Coupling: Tight
Coupling leads to serious quality issues in code repository.
1. Code becomes brittle and repercussions on
changing the above mentioned data structure can lead to defects &
unintended consequences. One way to avoid is to have relevant subset of data
structure passed around. eg: through design pattern-Data Transfer Objects (DTO).
2. Global variables are harmful by their very
nature, as they get passed around various components and modules [*]. Reduction in use of global variables will directly result
in reduction in coupling.
3. Abstract Factory and more advanced concepts like
DI/IOC containers reduce the coupling to a large extent. It’s well known that
when an interface / abstraction layer is introduced between high level and low
level module, breaks the dependency and thereby supports weak coupling.
4. On the other hand loose coupling, which is the
most desirous part here, improves code quality.
Note that
coupling cannot be completely wiped out from the software structures, but could
be consciously and meticulously reduced / minimized. Coupling is a necessary
evil. Also, I have not explained about different types of coupling, though a
veiled reference is mentioned above.
*Structured Design by WP Stevens, GJ Meyers and LL
Constantine
*Global Variable Considered Harmful by W Wulf and M
Shaw

No comments:
Post a Comment