liveBook · Manning

Tell-don't-ask

As explained in Unit Testing Principles, Practices, and Patterns

The tell-don't-ask principle advises objects to perform operations on their own data rather than exposing raw data for other objects to manipulate.

Tell-don’t-ask bundles data with the operations that use it. Clients tell an object to perform domain work instead of retrieving raw data and manipulating it themselves. section 7.2

The principle guides refactoring when a class performs work on another object’s data. Moving company logic into Company lets User delegate corporate-email checks and employee-count changes. section 7.2

From raw data to domain behavior

An application service first extracts companyDomainName and numberOfEmployees, then passes both into User.ChangeEmail. After refactoring, it constructs Company and calls user.ChangeEmail(newEmail, company); User asks Company whether the email is corporate and tells it to change its employee count.

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes
Demonstrates the principle through a refactoring from raw data manipulation to delegated domain operations.
Examples
Uses email changes, corporate-email classification, and company employee counts to contrast procedural and delegated designs.
What it assumes
Assumes familiarity with object-oriented classes, domain models, controllers, and application-service orchestration.
What you can do after
Apply it by moving operations on company data into Company and having User delegate those operations.
How it connects
Connects domain models, application services, controllers, factories, delegation, and misplaced responsibility.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Unit Testing Principles, Practices, and Patterns. The section links point to the parts of the book it draws on.