Coupling - A Smaller Object Approach To Software Solutions

In object-oriented software, we talk about the concept of coupling.  Put simply; this is a small object approach to our solution.  It is the opposite end of the spectrum from large-object, or monolithic, designs.  In my experience, a developer's bias towards cohesion or coupling often comes from their background.  Those that have come from functional languages and platforms are more comfortable with cohesion, while those that built components tend to use coupling.

It is hard not to point to flexibility as a primary strength of this approach.  It stands to reason that the more points of adjustment available, the more flexible the solution.  This example is easy to see in physical objects.  Remove all of the joints in your body, and you will be less flexible.  Likewise, return to our Lego example and consider what you can build with smaller as opposed to larger blocks and structures.

Another important strength of coupling is the ability to make changes with a smaller requirement of validation.  Thus, we can make improvements or changes and have less testing required.  This benefit can be critical to maintaining large systems without endless regression tests and unworkable release cycles.  We do need to verify we have not introduced unintended changes.  However, we have the ability to make tighter changes that are easier to debug.

The challenge with coupling is figuring out what goes where.  This conundrum is not different from the levels of normalization in a relational database.  There are situations where an attribute or method has overlap in the classes that use or need it.  This straddling of classes can make it challenging to place our bits of code properly.  On the other hand, those situations often point us to where a third-class shared by the two primaries is the best solution.