"Tell Don't Ask" describes a style of programming that can significantly improve the quality of one's code, but much like any principle, it's possible to take this style too far.
When this happens, we need to know how to recognize it and refactor back to something that's more enjoyable for ourselves and our colleagues to work on.
"Tell Don't Ask" was for me, and I think a lot of other developers, one of those mysterious phrases I heard people saying when discussing object-oriented programming, but could never quite parse what it meant through context alone. After working in Rails for a few years and seeing the pattern employed in several large codebases, I think I have a pretty solid working definition:
Instead of querying an object about its state, then making a decision on behalf of that object, it's better to send that object a message and let it make the decision. If that's not clear, don't worry, we're going to walk through all of that, and how it relates to "Tell Don't Ask."
Let's start with the literal phrase: "Tell Don't Ask." To "tell" is to give a command, to "ask" is to make a query. Take these two Rails models for example:
class JobApplicationSubmissionsController < ApplicationController def create if job_application.looks_good? && job_application.fits_job_description? job_application.submit! flash[:success] = "Good luck! Your application has been submitted!" else flash[:alert] = "Whoops! There was an error submitting your application!" end end private def job_application JobApplication.find(params[:job_application_id]) end end
class JobApplication < ApplicationRecord belongs_to :applicant belongs_to :job def submit! update!(status: :submitted) send_applicant_submission_confirmation_email send_hiring_manager_new_applicant_email end end
We have a controller responsible for submitting job applications. Job applications belong to both an applicant, and a job. When an applicant tries to submit an application for a job, we ask the application a few things about itself to make sure it's in good shape to be submitted, and then we tell it to submit itself. While this code definitely works, it's also an example of some code that definitely does not follow "Tell Don't Ask."
The giveaway here is that on line 3 of the controller, we're performing several queries (or "Asks") on the given job application object.
As a developer, one might start to remember reading about those "God Object"
things, and think "if the
doesn't know any of these things about a given
job_application, then why is
it the one handling these responsibilities?" and start to look for a way to
refactor the code.
Enter "Tell Don't Ask." What if instead of asking a given job application a bunch of questions about its current state, and making a decision on its behalf, we just tell the application what we want it to do and let it figure everything out from there? If that were the case, our code might look something like this instead:
class JobApplicationSubmissionsController < ApplicationController def create if job_application.submit! flash[:success] = "Good luck! Your application has been submitted!" else flash[:alert] = "Whoops! Looks like there was an error submitting your application!" end end private def job_application JobApplication.find(params[:job_application_id]) end end
class JobApplication < ApplicationRecord belongs_to :applicant belongs_to :job def submit! return unless can_be_submitted? update_status_and_send_emails end private def can_be_submitted? looks_good? && fits_job_description? end def update_status_and_send_emails update!(status: :submitted) send_applicant_submission_confirmation_email send_hiring_manager_new_applicant_email end end
The most noticeable improvement of this change is how much we've cleaned up our
create action. But we've also significantly reduced the complexity created by
this method. Now one object doesn't have to ask another object about its state,
and then make a choice based on that state.
So there ya have it - "Tell Don't Ask" is perfect in literally every way and should be followed religiously. Because there are clearly no downsides to this, right? RIGHT?
Through my experience following "Tell Don't Ask" semi religiously for a few years as a Rails developer, I've found a problem with it, especially in the context of Rails.
That problem is that it's very easy to break the "Single Responsibility Principle" which states that classes should have, at most (you guessed it) a single responsibility.
Let's go back to our example of a job postings application. It's not hard to imagine that in a month or so of time, the complexity of our model can grow quite explosively.
When this happens, much to our chagrin, we realize we've just created a
different "God Object." This kind of explosive growth is common in Rails models
that inherit from
ApplicationRecord, as they are responsible for many
different aspects of data management including validation, scoping, enums, and
In other words, sometimes classes already have a lot of responsibility, and adding methods onto them, even if it puts particular work closer to the data, might not be the best idea. So what can we do to fix it?
Well, if we have multiple responsibilities that need to get handled, and we want each class to only have one responsibility, let's make some more classes! In this context, classes like this are sometimes referred to as plain old Ruby objects or "POROs."
The solution that I've found to work best is basically a compromise between following, and not following, "Tell Don't Ask." Create a new class that is removed from the data, but is accessed through a public method added onto the class closest to the data.
class JobApplication < ApplicationRecord ... def submit! SubmitJobApplicationService.new(job_application: self).submit! end ... end
class SubmitJobApplicationService def initialize(job_application:) @job_application = job_application end def submit! return unless application_can_be_submitted? update_status_and_send_emails end private attr_reader :job_application def application_can_be_submitted? job_application.looks_good? && job_application.fits_job_description? end def update_status_and_send_emails job_application.update!(status: :submitted) send_applicant_submission_confirmation_email send_hiring_manager_new_applicant_email end def send_applicant_submission_confirmation_email ... end def send_hiring_manager_new_applicant_email ... end end
Yes, our new service object still has to "ask" our job application object about some things, but the value in this is that this is the only thing that service object will ever have to do.
You might also be asking, "why is the
JobApplication#submit! method still
there? Isn't that still keeping the responsibility tied to the model?" To which
I'd say some of it, but not all of it. The responsibility of how a job
application is submitted is still entirely confined to the service object; it's
just that our job application has knowledge of that service object.
The most significant advantage I see in this is writing code that reads the same
way as the language used by non-technical team members. In other words, if the
non-technical people working on this application (think project managers,
business analysts, etc.) use language like "a job application must be
submitted to its job", then having a method on the
JobApplication model called
submit! is much easier to learn, remember, and develop with than the name of
a service object stored somewhere completely separate from the model it's
performing on. The service object is already tied to the model by way of
what it does. Why not be explicit about that through our API?
As your application grows in size, that's usually a sign that it's growing in responsibility. As developers, we can make our lives considerably easier by dividing that responsibility up into small separate classes all working together. By doing this, we effectively reach the goal of "Tell Don't Ask" - keeping objects that don't need to be responsible for certain information away from that information - by doing the exact opposite of what it prescribes.
A nice side effect of this is that we can create methods that delegate functionality to those small classes so that the public API of our classes closely reflects the language used to describe what our application does.