16.6. Information Expert (or Expert)
Assign a responsibility to the information expert—the class that has the information necessary to fulfill the responsibility.
Solution
What is a general principle of assigning responsibilities to objects?
Problem
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.
In the NextGEN POS application, some class needs to know the grand total of a sale.
Example
|
Start assigning responsibilities by clearly stating the responsibility. |
By this advice, the statement is:
Who should be responsible for knowing the grand total of a sale?
By Information Expert, we should look for that class of objects that has the information needed to determine the total.
Now we come to a key question: Do we look in the Domain Model or the Design Model to analyze the classes that have the information needed? The Domain Model illustrates conceptual classes of the real-world domain; the Design Model illustrates software classes.
Answer:
If there are relevant classes in the Design Model, look there first.
Else, look in the Domain Model, and attempt to use (or expand) its representations to inspire the creation of corresponding design classes.
For example, assume we are just starting design work and there is no or a minimal Design Model. Therefore, we look to the Domain Model for information experts; perhaps the real-world Sale is one. Then, we add a software class to the Design Model similarly called Sale, and give it the responsibility of knowing its total, expressed with the method named getTotal. This approach supports low representational gap in which the software design of objects appeals to our concepts of how the real domain is organized.
To examine this case in detail, consider the partial Domain Model in Figure 16.3.
Figure 16.3. Associations of Sale.
What information is needed to determine the grand total? It is necessary to know about all the SalesLineItem 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.
As mentioned, it is in the context of the creation of interaction diagrams that these questions of responsibility often arise. Imagine we are starting to work through the drawing of diagrams in order to assign responsibilities to objects. A partial interaction diagram and class diagram in Figure 16.4 illustrate some decisions.
Figure 16.4. Partial interaction and class diagrams.
We are not done yet. What information is needed to determine the line item subtotal? SalesLineItem.quantity and ProductSpecification.price are needed. The SalesLineItem knows its quantity and its associated ProductSpecification; therefore, by Expert, SalesLineItem should determine the subtotal; it is the information expert.
In terms of an interaction diagram, this means that the Sale needs to send getSubtotal messages to each of the SalesLineItems and sum the results; this design is shown in Figure 16.5.
Figure 16.5. Calculating the Sale total.
To fulfill the responsibility of knowing and answering its subtotal, a SalesLineItem 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.
The design is shown in Figure 16.6.
Figure 16.6. Calculating the Sale total.
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 |
| SalesLineItem | knows line item subtotal |
| ProductSpecification | knows product price |
The context in which these responsibilities were considered and decided upon was while drawing an interaction diagram. The method section of a class diagram can then summarize the methods.
The principle by which each responsibility was assigned was Information Expert—placing it with the object that had the information needed to fulfill it.
Information Expert is frequently used in the assignment of responsibilities; it is a basic guiding principle used continuously in object design. Expert is not meant to be an obscure or fancy idea; it expresses the common “intuition” that objects do things related to the information they have.
Discussion
Notice that the fulfillment of a responsibility often requires information that is spread across different classes of objects. This implies that there are many “partial” information experts who will collaborate in the task. For example, the sales total problem ultimately required the collaboration of three classes of objects.
Whenever information is spread across different objects, they will need to interact via messages to share the work.
Expert usually leads to designs where a software object does those operations that are normally done to the inanimate real-world thing it represents; Peter Coad calls this the “Do It Myself” strategy [Coad95]. For example, in the real world, without the use of electro-mechanical aids, a sale does not tell you its total; it is an inanimate thing. Someone calculates the total of the sale. But in object-oriented software land, all software objects are “alive” or “animated,” and they can take on responsibilities and do things. Fundamentally, they do things related to the information they know. I call this the “animation” principle in object design; it is like being in a cartoon where everything is alive.
The Information Expert pattern—like many things in object technology—has a real-world analogy. We commonly give responsibility to individuals who have the information necessary to fulfill a task. For example, in a business, who should be responsible for creating a profit-and-loss statement? The person who has access to all the information necessary to create it—perhaps the chief financial officer. And just as software objects collaborate because the information is spread around, so it is with people. The company's chief financial officer may ask accountants to generate reports on credits and debits.
There are situations where a solution suggested by Expert is undesirable, usually because of problems in coupling and cohesion (these principles are discussed later in this chapter).
Contraindications
For example, who should be responsible for saving a Sale in a database? Certainly, much of the information to be saved is in the Sale object, and thus by Expert an argument could be made to put the responsibility in the Sale class. And the logical extension of this decision is that each class has its own services to save itself in a database. But this leads to problems in cohesion, coupling, and duplication. For example, the Sale class must now contain logic related to database handling, such as related to SQL and JDBC (Java Database Connectivity). The class is no longer focused on just the pure application logic of “being a sale;” it now has other kinds of responsibilities, which lowers its cohesion. The class must be coupled to the technical database services of another subsystem, such as JDBC services, rather than just being coupled to other objects in the domain layer of software objects, which raises its coupling. And it is likely that similar database logic would be duplicated in many persistent classes.
All these problems indicate violation of a basic architectural principle: design for a separation of major system concerns. Keep application logic in one place (such as the domain software objects), keep database logic in another place (such as a separate persistence services subsystem), and so forth, rather than intermingling different system concerns in the same component.[3]
[3] See Chapter 32 for a discussion of separation of concerns.
Supporting a separation of major concerns improves coupling and cohesion in a design. Thus, even though by Expert there could be some justification to put the responsibility for database services in the Sale class, for other reasons (usually cohesion and coupling), it is a poor design.
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 a following section).
Benefits
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).
Low Coupling
Related Patterns or Principles
High Cohesion
“Place responsibilities with data,” “That which knows, does,” “Do It Myself,” “Put Services with the Attributes They Work On.”
Also Known As; Similar To