The Single Responsibility Principle and Honest Naming

The solid principles are a set of principles designed to help you build good, maintainable software over time. With this post I’d like to dig into the first one — Single Responsibility.

Single responsibility means that every class you create should do one thing. That lets your classes have a very narrow focus. One of the many benefits is that it lets you compose your classes together more easily than if you have a class that’s doing many things. “Sounds simple!” I hear you say, “Just do one thing and one thing only. Good to go!”

Well, not so fast. As with most things in software engineering it gets a whole lot harder once you start putting it into practice. Let’s walk through an example. Let’s say you work for a software company that builds out flight tracking software for airports. Following the single responsibility picture you create an inboundFlightTracker that has method getInboundFlights that hands back a list of inbound flights and their arrival times.

You use this method to populate a dashboard for your flight controllers (is that what you call them?) of flights that are arriving in the airport. Then you get a new requirement that the dashboard also display flights that were inbound, but had to be re-routed. This extra information helps the controllers know what runways are opening up, and be ahead of extra problems.

”inboundFlightTracker already has all that data! It maintains a historical list of inbound flights, and it can use the change in destination to add a tag to the flight that says it was re-routed from our airport!” And you quickly add some code to getInboundFlights that includes a tag for re-routed flights and you’re done!

But what if we think about honest naming for inboundFlightTracker after this change? It’s not really an inboundFlightTracker anymore, now it’s an inboundFlightReRouteAwareTracker because it not only knows about inbound flights, but also knows about re-routed flights.

Next we get a requirement that we show a reason for the re-routed flight on the same dashboard. Was it mechanical failure or a health problem for the passenger?

We quickly add more code to getInbounndFlights to query another database that contains the reason for the re-routed flight. And what happens when we think about honest naming now? We have an inboundFlightReRouteReasonAwareTracker. And as the length of the name of the class grows we can quickly see that it’s not following single responsibility anymore.

It’s pretty easy to spot in this trivial example, but it’s a lot trickier when you’re coming to a class or code base for the first time. When you first crack open the inboundFlightTracker you’d ask yourself, “Is a re-route reason an integral part of a re-route? Is a re-routed flight really still an inbound flight in some sense?”

Here are some questions to ask yourself as you sort through a class you haven’t seen before

1. How many nouns and adjectives do I need to run together to get an accurate class name?
2. How similar or different those nouns and adjectives? Are they different enough you should break out some functionality?
3. How long is the class? How many different methods does it have? How many different behaviors are there?

I hope that’s some helpful perspective on how to get insight into the single responsibility principle.