Tell, don't ask—the gateway to loosely coupled architecture
A simple trick to avoid common traps in coupling and monolith systems thinking with a practical video from a live streamed pair programming session.
Hey it’s Denis. This is Part 3 of a series called Software Engineering Fundamentals.
How are you enjoying it so far?
💡 The big lightbulb moment is at the end of this article.
Tell—Don’t ask?
This publication from the authors is the closest to the original that I managed to find that’s still in good internet–shape. In short, it is the Law of Demeter put in practice.
Objects should be responsible for their own data, and those objects should be the ones to make decisions based on that data, not the application at large.
The fundamental goal […] is to write shy code—code that doesn’t reveal too much of itself to anyone else and doesn’t talk to others any more than is necessary.
A set of rules that minimises the cognitive load of the engineer by putting public-facing decision-making behavior close to private data. Following tell, don’t ask (TDA for short) helps you navigate your object’s responsibilities and boundaries.
Practical Example
Here’s a piece of code we co-wrote live on one of our streams. It’s a simplified example to model the practice. As all models, it is an imperfect representation of a real life engineering situations. Feel free to poke holes in it.
Checklist
The refactoring above shows the main idea behind TDA: move your behavior to the data. Here’s how you can find candidates in your own code:
Asking for private data. Getters are notorious for this. Check your ORM-generated entities. Check your DTOs.
Traversing chains of neighbours to get the right data. This is the so-called train-wreck and is a violation of the Law of Demeter.
Your mocks require intricate data fixtures. When behavior and private data are separate they create a web of dependencies. These notoriously float to the surface in testing—especially developer testing on the unit and functional level.
You’ll notice a pattern here: private data is leaked when generic abstractions make it too close to your business logic.
This is why separation from frameworks and infrastructure makes your code easier to change (ETC). That is the philosophy behind clean and hexagonal architecture.
Naïve interpretations
At a glance many engineers mistake TDA for Dont-repeat-yourself’s and Single-responsibility-principle’s combined bastard child: single-function classes with void methods. Such objects are reminiscent of self-executing commands.
But state has to go somewhere. Ideally someplace that will make change easy. Change is easy when minimising number of external-facing moving pieces.
However, architecturally TDA is closer to CQRS and event carried state transfer.
Boundaries
Commands are imperative in nature, reminiscent of traditional C code. Boundaries of knowledge are scattered for the engineer. State is external and behavior is internal. To mock behavior you have to precisely engineer state. To test data validity, you have to reverse-engineer the private behavior.
Does that sound like your normal day at your office?
Notice the additional types introduced by the functional boundar: calculate in the above example has to know about the return types and input types of getEngine. By making state internal and behavior external the natural boundary of “knowledge” is drawn around two areas: the private state the object owns and the guarantees its methods provide.
Learn more on the stream
Conclusion
Tell, don’t ask is a mental shift towards thinking. Apply it to:
Maintain that software you produce is easy to change
Design methods without being coupled to their dependencies’ inputs
Create natural promotions of DTOs to units of behavior
Retain testability by avoiding a mocking web of intricate data fixtures
It is best applied to critical and valuable paths in your codebase that:
Ask for private data
Traverse long object chains
Require complex mocks to test
Ready to take it to the next level?
Technical Coaching continues to be the most prominent boost to software engineer’s career, outperforming conferences, workshops and even the best books.
