User Tools

Site Tools


principles:tell_don_t_ask_information_expert

This is an old revision of the document!


Tell Don't Ask/Information Expert (TdA/IE)

Variants and Alternative Names

  • Information Expert or Expert in 1)
  • Do It Myself in 2)
  • Tell, don't Ask in 3)

Context

Principle Statement

  • Assign a responsibility to that module which has the largest subset of the required information.
  • Don't ask an object for information, make computations and set values on the object later. Tell the object what it should do.

Description

Each module has a set of responsibilities. Subsystems have specific tasks, packages group several related classes, classes have methods and attributes, and so on. So there is a kind of mapping between modules and responsibilities. This mapping is good when the information which is necessary to fulfill the given task is present in the given module so there is no need to acquire all this information.

Rationale

When this principle is not adhered to, then a module has a responsibility for which it is lacking some information. So in order to fulfill the task the module has to first acquire the needed information by invoking other modules. This increases the dependencies between the modules (which may lead to ripple effects).

Strategies

  • Assign a responsibility to the class that has the largest subset of the needed information.
  • Mirror functionality of composed objects to the interface of the class instead of having a getter-method returning the composed object
  • Have the objects operate on their own data using appropriate methods. Avoid getters and setters.

Caveats

Sometimes assigning responsibilities using IE results in bas solutions (high coupling, low cohesion). This is because IE just focuses on the availability of data. So for example IE would demand domain objects saving themselves to the database. This is bad since it couples the domain objects to the database interface (JDBC, SQL, etc.) and lowers cohesion by adding unrelated responsibilities to the classes. Here it is better to give the task of persisting the domain objects to a separate class.4)

See also section contrary principles.

Origin

Craig Larman: Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development

Evidence

Relations to Other Principles

Generalizations

Specializations

Contrary Principles

Complementary Principles

  • Low Coupling Adhering to IE typically leads to low coupling as there is less need to communicate with other modules to get the necessary information. But in some cases IE also increases coupling (see caveats.
  • High Cohesion Adhering to IE typically leads to high cohesion as responsibilities which belong together typically operate on the same data. But in some cases IE also lowers cohesion (see caveats).
  • Model Principle (MP): TdA/IE tells how to distribute functionality among the natural classes which are created according to the Model Principle.
  • Information Hiding/Encapsulation (IH/E): Assigning responsibilities to objects using Information Expert may accidentally break encapsulation. It typically does not but it has to be considered. Furthermore TdA is about not having getter methods returning constituent parts of a module. Encapsulation can be another reason for that.

Principle Collections

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU

Example

Description Status

Further Reading

1)
Craig Larman: Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development
2)
Peter Coad: Object Models: Strategies, Patterns and Applications – as stated in Craig Larman: Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development, p. 297
3)
Andrew Hunt and David Thomas: The Art of Enbugging – probably not the original source of this wording(?)
4)
see Craig Larman: Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development, p. 298
principles/tell_don_t_ask_information_expert.1630579890.txt.gz · Last modified: 2021-09-02 12:51 by 65.21.179.175