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
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