Information Expert GRASP Pattern

Information Expert is the GRAS Patterns (General Responsibility Assignment Software Pattern)

Read about GRASP Patterns: GRASP Patterns Overview

Problem

What is a general principle of assigning responsibilities to objects?
A Design Model may define hundreds or thousands of software classes, and an application may require hundreds or thousands of responsibilities to be fulfilled. During object design, when the interactions between objects are defined, we make choices about the assignment of responsibilities to software classes. Done well, systems tend to be easier to understand, maintain, and extend, and there is more opportunity to reuse components in future applications.

Solution

Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility.

Example

Let's consider Point of Sale (POS) application: a Brief overview of POS application.

Application for a shop, restaurant, etc. that registers sales.

Each sale is of one or more items of one or more product types and happens at a certain date.

A product has a specification including a description, unitary price, and identifier.

The application also registers payments (say, in cash) associated with sales.

A payment is for a certain amount, equal or greater than the total of the sale.

Problem statement: Who's responsible for knowing the grand total of a Sale?

In the POS application, some class needs to know the grand total of a sale.

Start assigning responsibilities by clearly stating the responsibility.

By Information Expert, we should look for that class of objects that has the information needed to determine the total.

It is necessary to know about all the SalesLineltem instances of a sale and the sum of their subtotals.

A Sale instance contains these; therefore, by the guideline of Information Expert, Sale is a suitable class of object for this responsibility; it is an information expert for the work.

We are not done yet. What information is needed to determine the line item subtotal? SalesLineltem.quantity and ProductSpecification.price are needed. The SalesLineltem knows its quantity and its associated ProductSpecification; therefore, by Expert, SalesLineltem should determine the subtotal; it is the information expert.

In terms of an interaction diagram, this means that the Sale needs to send get-Subtotal messages to each of the SalesLineltems and sum the results; this design is shown in Figure :

To fulfill the responsibility of knowing and answering its subtotal, a Sales- Lineltem needs to know the product price. The ProductSpecification is an information expert on answering its price; therefore, a message must be sent to it asking for its price.

Complete Class Diagram

In conclusion, to fulfill the responsibility of knowing and answering the sale�s total, three responsibilities were assigned to three design classes of objects as follows

Design Class	Responsibility
Sale	knows sale total
SalesLineltem	knows line item subtotal
ProductSpecification	knows product price

Sample Code

Let's write sample method in Sale Domain model class.

public class Sale {
 //...
 public double getTotal(){
  double total = 0;
  for (SalesLineItem s : salesLineItem) {
   ProductSpecification prodspec
   = s.getProductSpecification();
   total += s.getQuantity()*prodspec.getPrice();
  }
  return total;
 }
}

This is above code is enough? It is not enough right because here we need getSubTotal from salesLineItem.

Let's create the method in SaleLineItem domain model class.

public class SalesLineItem {
  //...
  public double getSubTotal(){
  return this.getQuantity()
   productSpecification.getPrice();
  }
 }

Observe ProductSpecification Domain model provides getPrice method gives a price.

Fulfillment of a responsibility may require information spread across different classes, each expert on its own data.

Benefits

Information encapsulation is maintained since objects use their own information to fulfill tasks. This usually supports low coupling, which leads to more robust and maintainable systems. (Low Coupling is also a GRASP pattern that is discussed in the following section).

Behavior is distributed across the classes that have the required information, thus encouraging more cohesive "lightweight" class definitions that are easier to understand and maintain. High cohesion is usually supported (another pattern discussed later).