Software patterns - GRASP (Part V – Low Coupling)

Objective

Preface

We have explored what are patterns and GRASP (in part I), Information Expert in part II and Creator in part II and “Controller” in part IV. In this part V, we would focus on next GRASP pattern named “Low Coupling”. The principle behind this pattern is “How to support low dependency and increased reuse?” and “How to assign the responsibilities so that the coupling is low?”

Coupling refers to connectedness or linking. It is a measure of how strongly one class is connected to or has knowledge (information or knowhow) of or relies/depends upon the other classes. With experience, programmers would agree on something i.e. making changes is always been the hardest task and given a chance all would like to work upon systems from ground up. With increased complexity in the programming world and programming languages, designing is becoming driver for system’s overall quality and usability. Designing for low connectedness is an important activity which can help to have a system in such a way that the changes in one element (sub-system, system, class, etc) will limit changes to other elements. Being at extreme, is it possible to have no coupling at all? The answer to this question is “No” as without having any connection; a system can’t be called a system.

High coupling (high dependency, linking and connectedness) leads to

·         Cascade of changes – this forces changes in related classes

·         Harder to reuse its use of highly coupled elements requires the additional presence of the classes it is dependent on

·         Harder to understand in isolation

Problem: How to reduce impact of changes and encourage reuse?

Solution: Assign a responsibility so that the coupling (linking classes) remains low

Approach:

Step I: Closely look for classes with many associations to other classes.

Step II: Look for the methods that rely on a lot of other methods (or methods in other classes i.e. dependencies

Step III: Rework the design so as assign responsibilities to different classes in such a way that they have lesser association and dependency.

Description 

Let’s extend an example of POS (Point Of Sale) systems carried in series of articles. In the domain model, following classes like Register, Payment and Sale are identified. These classes are shown in the left part of diagram (Fig. No.1). There are many system operations such as closing a sale, make payment etc which are related to business function “Sales”.

Fig No. 1

Table No. 1

The common forms of coupling for A to B include

·         A has a data member which refers to B instance

·         A has a method which B is an argument

·         A is direct or indirect subclass of B

·         B is an interface and A implements B

Related Patterns: The pattern related to is “High Cohesion”.

Benefits

·         Maintainability -Little or not affected by changes in other components

·         Understandability- simple to understand in the isolation

·         Reusability- convenient to reuse and easier to grab hold of classes

Liabilities / Contradictions:

·         Coupling to stable elements (classes in library or well tested classes) doesn’t account to be a problem.

Summary & Conclusion

In this part, we discussed the “Low Coupling” and also the principle behind this. We discussed the steps for assigning responsibility. We saw practical example from POS (Point Of Sales) and explanation as how to have low coupling.

To reiterate, following such patterns for design would result into highly maintainable, robust and reusable systems.

Happy  Designing!!!

References:

Applying UML and Patterns, Craig Larman