Or how the Tell, Don’t Ask Principle can help us express intent
Software development nowadays is a complex process that while entailing many scientific aspects, it can also be seen as a form of art. Even rules and best practices aside, a piece of code will always mirror the mind, soul and creativity of the developer that created it. As such a developer can always benefit from borrowing elements and studying great masters, not only of Computer Science, but of other arts too, such as the art of storytelling. After all, a craftsman must keep honing their skills.
Programming and storytelling are very similar in nature. For example, both are expressed via written language and are means of communication (either seen as a set of instructions to a machine or as code read by a colleague). Both have rules, best practices, techniques, and structure. How can a developer though, find value from studying storytelling?
A great technique in storytelling is to show rather than tell to your audience what a character may be feeling or experiencing. By telling, you simply inform the reader, presenting them with factual statements, while by showing, a more intimate connection is being created. A mental model of the scene and the emotions that the characters are feeling, instead of simply stating information.
“Don’t tell me the moon is shining. Show me the glint of light on broken glass.”
― Anton Checkhov
In programming, there is a similar principle that is known as Tell, Don’t Ask that aims to control coupling between classes. As a good storyteller is expected to show to the audience instead of directing telling them information, a software developer can also tell (command) its objects to behave as expected instead of querying them for their internal state.
To explain it further, let’s see an example of a trivial but typical ask object:
Want to read this story later? Save it in Journal.
The above car class is quite simple with just a single private field, a public getter and a public setter. When the developer wants to get information about the state of the lights of the car, in order to turn them off for example, would ask the car instance by invoking the getter in an if statement and then proceed to set the lights off by calling the setter.
By following the Tell, Don’t Ask principle, we can refactor our object to the following:
Now instead of asking, we can tell the object to turn the lights on or off and trust it to behave as expected. But what have we accomplished here?
As developers, day in and day out, we write and read code. Actually, we might be spending more time reading than writing. By following the principle of tell, don’t ask, not only we have reduced coupling (imagine a class with actual internal dependencies and not a single lights field) but also we have added intent to our code. As a good storyteller would have done, we have expressed our intention to our fellow reader (developer) and we have created a narrative. The car object, can now be a character in a bigger picture, while the lights method can be our own version of the glint of light on the broken glass.
As all matters in our craft, the above technique is not appropriate to always being followed, but instead the developer should use it depending the situation at hand. On an upcoming article we will examine other ways and techniques to aid us in telling a story via our code.
Till then don’t stop creating and exploring ideas!