What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Tell, don't ask and practical object collaboration

Moves invariant-sensitive decisions toward the owning object while keeping orchestration, queries, and cross-boundary work appropriately explicit.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Tell, don't ask means asking the object that owns a rule to perform the decision instead of extracting its state and deciding elsewhere. Instead of reading Order.Status, Items, and Total in several services to decide whether cancellation is allowed, I call order.Cancel(reason). The Order checks its state and records a valid transition. The application service still coordinates loading, authorization, persistence, and notifications. The principle moves the decision, not the entire use case, into the entity.

Full answer below

Practice focus

Behavioral APIs, feature envy, invariants, orchestration, query models, command-query separation, and pragmatic collaboration.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Tell, don't ask means asking an object to perform a meaningful operation instead of pulling out its state and making its decision elsewhere. It is most valuable when the object owns an invariant that callers could otherwise duplicate or bypass.
Tell, don't ask means asking the object that owns a rule to perform the decision instead of extracting its state and deciding elsewhere. Instead of reading Order.Status, Items, and Total in several services to decide whether cancellation is allowed, I call order.Cancel(reason). The Order checks its state and records a valid transition. The application service still coordinates loading, authorization, persistence, and notifications. The principle moves the decision, not the entire use case, into the entity.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Applying it mechanically can create chatty objects or hide simple read logic behind commands. Reporting and UI queries should project the data they need rather than sending behavior messages to hundreds of objects. Cross-aggregate decisions may belong in a policy or application service because no single object owns all required state. I use the principle to reduce feature envy and duplicated rules, not to ban getters.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Interpreting the principle as never exposing data.
Moving database and HTTP calls into entities.
Using behavior objects for large reporting queries.
Forcing one entity to own cross-aggregate workflows.

What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement