Software patterns - GRASP (Part V – Low Coupling)

Vishvvas
Posted by in Best Practices category on for Advance level | Points: 250 | Views : 8139 red flag
Rating: 5 out of 5  
 1 vote(s)

In this part of article series for "Software patterns- GRASP", we would run through the process of assigning responsibilties so has to support low dependency and encourage resuse i.e. to implement the pattern "Low Coupling".

Objective


To understand the GRASP pattern “Low Coupling”


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

Class

Relationship with other classes

Responsibility and method

Remarks

“Register” of Design I

Creator of the “Payment”

Controls the “Sale”

Controls and coordinates the sale through makePayment()

 

So if Sale or payment changes its going to affect the Register. This results in tight coupling

“Register” and “Sale” of Design II

Controller of “Sale” and “Sale” being the creator of “Payment”

Creating an instance “create”

Controlling the Sale through makePayment()

This results in division of responsibilities and hence low coupling as “Register” need not know about the payment.

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



Page copy protected against web site content infringement by Copyscape

About the Author

Vishvvas
Full Name: Vishwas Sutar
Member Level: HonoraryPlatinum
Member Status: Member,MVP
Member Since: 5/30/2011 2:13:10 AM
Country: India

http://www.dotnetfunda.com
Extensive and rich experience across gamut of technologies and programming languages like PB,VB,C++,VB.NET, C#, Classic ASP,ASP.NET, ASP.NET MVC.

Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)