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
Design Nutcracker 