Software patterns - GRASP (Part III – Creator)

Objective

To understand the GRASP pattern “Creator”.

Preface

In the part I, we have explored what are patterns and also came to know about GRASP. In the part II we visited the pattern named “Information Expert (or just Expert)”.  In this article we would focus on next GRASP pattern “Creator”. The principle behind this pattern is “Who should be assigned the responsibility of Creation of object?”

Problem: Who creates the new instance of some class?

Solution:

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

·         A aggregates (whole-part relationship) B objects

·         A contains B objects

·         A records instances of B objects

·         A closely uses B objects

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

Approach:

Step I: Closely look at domain/ design model and ask: who should be creating these classes?

Step II: Search for the classes who create, aggregate etc.

Step III: Assign the responsibility of creation

Description

Let’s extend an example of POS (Point Of Sale) systems explained in previous part. This is what we come across malls where there are many POS counters. In the domain model, following classes are identified. These classes are shown in the left part of diagram (Fig. No.1). A class “Register” represents the sales register. This would have details of all sales done. As the “Register” aggregates the “Sale”, it fulfils the first criteria of the solution. Similarly the “Sale” contains the “SaleLineItem”. Hence “Register” should create the instance of “Sale” and “Sale” should create instance of “SaleLineItem”.

Fig. No. 1

Table No. 1

Following diagram depicts the assignment of responsibilities and corresponding methods.

Fig No. 2

Benefits:

·    Support low coupling

·    The responsibility is assigned to a class which fulfils the criteria thus separating the logic for creation and actual execution.

Liabilities /Contradictions:

·    Sometimes creation may require significant complexity. Many a times there would be tight coupling among the creator and create class. Also the task of destroying the objects  is to be thought of. Recycling of such instances (pooling) becomes important for the performance reasons.

·    In many scenarios the creations is conditional and it may be from family of classes making it very complex.

·    For creation of family of classes or to tackle the creation and recycling, other patterns are available which are factory, abstract factory etc.

Summary and Conclusion

In this part, we discussed what Creator (sometimes called only “Expert”), the principle behind this. We discussed the steps for assigning responsibility. We saw practical example from POS (Point Of Sales) and explanation for responsibility of creating instances with a sequence diagram. The benefits and contradiction are mentioned with reference to availability of other patterns too. This pattern better be seen as principle and for actual implementation other patterns like singleton, factory, builder be studied. To reiterate, following patterns for design would result into highly maintainable, robust and reusable systems.

Happy  Designing!!!