In this part of article for "Software Patterns- GRASP", we would explore the pattern "Information Expert" and run through the process of assigning responsibilties to such class.
Objective
To understand about the GRASP pattern “Information Expert’.
Preface
In the part I, we have explored what are patterns and also came to know about GRASP. In this article we would focus on GRASP pattern “Information Expert”. The principle behind this pattern is “Who should be assigned the responsibility?”
Problem: Any real world application has hundreds of classes and thousand of actions. How do I start assigning the responsibility?
Solution: Assign a responsibility to Information Expert, the class that has information necessary to fulfil the responsibility.”
Generally, if domain model is ready then it is pretty straight forward to assign the responsibilities and arrive at design model.
Approach
Step I: State the responsibility clearly.
Step II: Search for the classes who have the information needed to fulfil the responsibility.
Step III: Assign the responsibility
Description
Let’s take an example of POS (Point Of Sale) systems. 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). Let’s think about some responsibility.
Who should have the responsibility of calculating the Sales Total?
Sales Total =Sum of (Unit price X quantity of sale line item)
E.g. a person is buying 2 line items, toothpaste (2 no’s) and soap (2 no’s) are being bought
Sales total = (Price of toothpaste)* (quantity of toothpaste) + (Price of soap)* (quantity of soap)
In the above scenario, the classes Sale, “SaleLineItem” and “ProductSpecification” has the information such as unit price for item/ product (“ProductSpecification”), sales quantity (“SaleLineItem”) and no. of saleLineItems (“Sale”). So the responsibility of arriving at Sales Total needs to be assigned to all these classes. Now in this case, If the class is encapsulating data members then maintaining these data values is the responsibility of the class and it should provide the get and set methods for accessing such data.
Class |
Data Values Encapsulated |
Responsibility and method |
ProductDescription |
UnitPrice |
Getting the unit price getPrice() |
SaleLineItem |
Quantity of items and hence the subtotal for particular item
Quantity X Unit Price |
Getting the Subtotal
getSubTotal() |
Sale |
No. of Saleline Items, data and time
Sum of (getSubTotal() x SaleLine item ) |
Get the Total of Sales
getTotal() |
It is demonstrated in right portion of above diagram (Fig. No.1).
Following diagram depicts the assignment of responsibilities and corresponding methods.
Benefits:
- Encapsulation is maintained as objects use their own data to fulfil the task.
- Support low coupling
- Behaviour (responsibility) is distributed across the classes that have the required information thus encouraging the highly cohesive lightweight classes
Liabilities /Contradictions:
- Sometimes while assigning responsibilities, lower level responsibilities are uncovered e.g what the profit or loss for a particular sale?
- Not all the times the application of this pattern is desirable. Consider the responsibility of saving such Sale to database. By the principle for this pattern, it should be the class “Sale” to carry out this responsibility but as experienced programmer we know it is hardly the case. The DAL (Data Access Layer) carries out this responsibilities may be by providing methods such as SaveSale() into some controller class.
Summary and Conclusion
In this part, we discussed what Information Expert (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 and its assignment. We mentioned the benefits and contradiction too. Definitely, it bit difficult to envisage the responsibilities and their assignment, but if we are following domain driven design i.e. identifying the domain objects and then refining into the design objects, then we can apply such patterns and principles to best of their usage and develop a design which would result into highly maintainable, robust and reusable systems.
Happy Designing!!!