17.11. Information Expert (or Expert)
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. If we've chosen well, systems tend to be easier to understand, maintain, and extend, and our choices afford more opportunity to reuse components in future applications.Solution Assign a responsibility to the information expertthe class that has the information necessary to fulfill the responsibility.Example In the NextGEN POS application, some class needs to know the grand total of a sale.
Start assigning responsibilities by clearly stating the responsibility. |
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.
- Otherwise, look in the Domain Model, and attempt to use (or expand) its representations to inspire the creation of corresponding design classes.
Figure 17.14. Associations of Sale.
Figure 17.15. Partial interaction and class diagrams.
Figure 17.16. Calculating the Sale total.
[View full size image]
Figure 17.17. Calculating the
Sale total.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.Chapter 33 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 we could find some justification for putting the responsibility for database services in the Sale class, for other reasons (usually cohesion and coupling), we'd end up with a poor design.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 a 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).
Related Patterns or Principles
- Low Coupling
- High Cohesion
Also Known As; Similar To "Place responsibilities with data," "That which knows, does," "Do It Myself," "Put Services with the Attributes They Work On."