Software patterns - GRASP - Summary of article series

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

This is last article of series for "Software patterns- GRASP" and we would summarize the discussions we had so far and conclude the series.

Objective

To summarize the GRASP patterns we have discussed till date.

 

Introduction

We have explored what are patterns and GRASP (in Part I), Information Expert in part II and Creator in Part II, Controller in Part IV, “Low Coupling” in Part V and “High Cohesion” in Part VI and Polymorphism in Part VII, Pure Fabrication in Part VIII, “Indirection” in this Part IX, and  “Protected Variations” in Part X. This way the GRASP patterns are concluded. This is the last article devoted to summary of GRASP pattern discussions we had till date.

I am sure these articles have introduced you to advanced concepts in pattern oriented software development. These kinds of topics are generally known to developers pursuing/ pursued the higher education in software engineering field. Looking at the real usability of such principles and patterns, it feels that such study would help developers to inculcate the strong design skills. In turn it would result in far more robust, extendible and maintainable systems.

According to Larman, “The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology" (Larman, Craig. Applying UML and Patterns - Third Edition). Thus, GRASP is really a mental toolset, a learning aid to help in the design of object oriented software.

Software engineering practices are relatively unknown or little known to the developers fraternity and there is a supposition that it’s all in theory and practically implacable. But if one sees the examples in such articles, one can realize that it’s easy to understand and implement such practices and derive their benefits. Knowledge is power and if acquired and applied in right sense, it brings out astounding results.

OOP-object oriented programming is a buzzword for a while now but if one looks into reality, one can come to conclusion that this is one of the most misunderstood subject. OOPs always equated with encapsulation, inheritance, and polymorphism but there is a lot beyond that. To become a true practitioner of OOPs, one needs to change the mindset from “just making things happen” to “make best things happen”. I have seen developer complaining that the budget and time are big challenges in a path for best practices implementation, but it is other way round, if understood correctly such best practices results in huge saving of budget and time and better quality. They say “QUALITY DOESN”T COST”.

Let’s have a concluding look at the patterns we discussed and as well as the problems and solutions.

SN

Name of the Pattern

Problem

Solution

1

Information Expert

Any real world application has hundreds of classes and thousand of actions. How do I start assigning the responsibility?

Assign a responsibility to Information Expert, the class that has information necessary to fulfil the responsibility.”

2

Creator

Who creates the new instance of some class?

Assign class A the responsibility to create an instance of class B if….

(i)  A aggregates (whole-part relationship) B objects

(ii) A contains B objects

(iii)A records instances of B objects

(iv) A closely uses B objects

(v) A has initializing data that is needed while creating B objects (thus A is an expert with respect to creating B)

3

Controller

Who should be responsible for handling a system event?

 

Assign the responsibility for handling a system event message to a class representing one of the following

(i)      A class that represents the overall system, device, or sub-system (facade controller) e.g. Jukebox.

(ii)    A class that represents a use case within which the system event occurs (a session controller or use case controller) Example: makeSaleHandler, makeSaleCoordinator, etc.

(iii)   Represents the overall business (facade controller)

(iv)  Represents something in real world that is active (role controller)

4

Low Coupling

How to reduce impact of changes and encourage reuse?

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

5

High Cohesion

How to keep classes focused and manageable?

Assign responsibility so that cohesion remains high.

6

Polymorphism

How to handle alternatives based on type? How to create pluggable software components?

Assign responsibility for the behaviour (using polymorphic operations) to the types for which the behaviour varies.

7

Pure Fabrication

Who should be responsible when an expert violates high cohesion and low coupling?

Assign the responsibility for handling a system event message to a class which is new fictitious (artificial) and doesn’t represent a concept in domain.

8

Indirection

How to combine Low coupling and high potential for reuse?

Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.

9

Protected Variations.

How responsibilities should be assigned in such a fashion that the current or future variations in the system do not cause major problems with system operation and/or revision?

Assign responsibilities to create stable interfaces around current and future variations.

For quick reference, let’s also have the index and URL’s for these articles on www.dotnetfunda.com

 

SN

Article

Article URL

1

Introduction

Software patterns - GRASP (Part I - Introduction)

2

Information Expert

Software Patterns - GRASP (Part II – Information Expert)

3

Creator

Software patterns - GRASP (Part III – Creator)

4

Controller

Software patterns - GRASP (Part IV – Controller)

5

Low Coupling

Software patterns - GRASP (Part V – Low Coupling)

6

High Cohesion

Software patterns - GRASP (Part VI – High Cohesion)

7

Polymorphism

Software patterns - GRASP (Part VII – Polymorphism)

8

Pure Fabrication

Software patterns - GRASP (Part VIII – Pure Fabrication)

9

Indirection

Software patterns - GRASP (Part IX – Indirection)

10

Protected Variations.

Software patterns - GRASP (Part X – Protected Variations)



Conclusion

In this series of articles, we discussed the GRASP patterns and practical examples. I am sure after reading these articles, the readers would have got a good grasp of these patterns and it would help them to design the systems better. I hereby put an end to this series with this last article summarizing the journey so far and I sincerely express my thanks for all the readers.

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

Happy Designing!!!

Reference

 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)