Software Design - Finding Balance With Coupling And Cohesion

We have spent a few episodes looking at cohesion and coupling.  Now it is time to find balance in these two software design approaches.  Each approach has strengths and weaknesses.  Therefore, our best approach is to combine the strengths while offsetting the weaknesses.  This best-fit approach is not as difficult to achieve as it may seem.

The large object approach allows us to access data and methods quickly.  We have a short path to get to these items as the layers of abstraction have been minimalized.  The greatest value of this approach is when we have data or methods that are often used.  There is little value to this efficiency for items we rarely utilize.

For example, think about a daily report vs. a monthly report.  The calculations that generate the monthly report can be less efficient and time-consuming because they are rarely utilized.  A cost of 15 minutes for a feature is only paid once a month.  The daily report has a higher value of performance.  That same addition of fifteen minutes adds up to a loss of over a day per month.  More iterations equate to a greater value for performance improvements.

We can push our primary data and features into a few large objects.  That helps us with performance.  However, it may seem overly taxing to a system to load all of the lesser-used data and methods in a single class.  Instead, we can utilize smaller objects that can be quickly instantiated and freed for less frequent needs.  The overhead cost of initialization and cleaning up these small objects is often a wash.  We do not use them much.  Thus, the slower performance has little overall impact on our system.

We pointed to flexibility as a strength of the coupling approach.  However, we did not mention that coupling can be done with a combination of large and small objects.  We see this thought process played out in patterns and frameworks like the flyweight and object factories.  Even big things can have some small (replaceable) moving parts.  That is the key to the blended approach.  Keep the common things close and store the less-common features in easy-to-initialize small objects.