Software Patterns - GRASP (Part II – Information Expert)

Posted by in Best Practices category on for Advance level | Points: 250 | Views : 26619 red flag

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.


To understand about the GRASP pattern “Information Expert’.


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.


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


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.


Data Values Encapsulated

Responsibility and method



Getting the unit price getPrice()


Quantity of items and hence the subtotal for particular item

Quantity X Unit Price

Getting the Subtotal



No. of Saleline Items, data and time

Sum of (getSubTotal() x SaleLine item )

Get the Total of Sales


It is demonstrated in right portion of above diagram (Fig. No.1).

Following  diagram depicts the assignment of responsibilities and corresponding methods.


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

Page copy protected against web site content infringement by Copyscape

About the Author

Full Name: Vishwas Sutar
Member Level: HonoraryPlatinum
Member Status: Member,MVP
Member Since: 5/30/2011 2:13:10 AM
Country: India
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)