SOLID: The Single Responsibility Principle

By Aasif Khan | December 29, 2021 7:33 pm  | 4-min read

Understanding software design principles is what sets good developers apart from great developers. Anyone can write code, but not every coder writes great code. Can the Single Responsibility Principle help you write great code?

Getting better at coding starts with the iOS development fundamentals: variables, functions, Swift syntax, data structures, algorithms and the iOS SDKs. Once you’ve learned those basics, and built a few app projects, it’s time to level up and master the SOLID software design principles.

Just like you can design graphics, a user interface or a user interface, you can also design software. The code is merely the paint on the canvas – the design is the thoughtfulness that went into writing that code. The goal of a good app architecture is to make code easier to read, easier to maintain, simpler to reuse, easier to debug, and easier to extend.

As a developer, you can pick from many software design principles and architectural patterns: SOLID, DRY, GRASP, KISS – not to mention approaches like MVC, MVP, MVVM, FRP and VIPER.

Understanding SOLID trumps any of the other approaches every time, because SOLID lies at the foundation of every one of the other approaches to software design. (In addition to DRY and KISS. More on those later.)

SOLID is a mnemonic and it stands for:

• Single responsibility principle
• Open-closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Let’s get into the first one: the Single Responsibility Principle. Here we go!

Single Responsibility Principle: Do One Thing Only

The first principle of SOLID is the Single Responsibility Principle (SRP). You can roughly translate that as Do One Thing Only.

In Swift programming you use classes to create your apps. A class is a basic building block in your app, a component that has one purpose. The single responsibility principle states that a class should only have one reason to change.

In reality, this means two things:

A class should only do one thing
There is only one reason to change a certain class
When a class has a single responsibility, it does one thing, and therefore only has one reason to change: when the “thing” it does, changes! This is where the name “single responsibility principle” comes from.

You violate the single responsibility principle when a class has multiple responsibilities. This becomes clearest when you find that there are more than one reasons to change a class.

Are you unfamiliar with app architecture, and why it’s important? Start with this primer: Why App Architecture is Important.

A Practical Example of SRP

Let’s look at a practical example.

You’re building an app that generates reports. Every day the app generates a report about stuff, like school grades, productivity metrics, incoming emails or tweets you sent on Twitter.

You could create a class ReportGenerator in your app. It takes the data for the report, formats it, and exports the report to a PDF file.

A while later, you decide you want to change the way the report looks. It needs a new font, some different colors, and an extra data table. You also decide to instead of exporting to PDF, you’ll now export simple JPEG images.

Suddenly, you remember the single responsibility principle, and you realize your mistake! Instead of one responsibility, your class has three:

1. Gather data for the report
2. Create the report formatting
3. Export the report

What’s a Single Responsibility?

It’s crucial to understand something here.

The single responsibility is defined as “one reason to change”, not “one responsibility”. You could argue that “generating reports” is one responsibility, and you’d be right. Why would you break it up in multiple classes, then?

The essential difference is “reason to change”. These three classes now each have one reason to change: change the data gathering, change the report formatting, and export it. That’s easier to maintain and debug than 1 class with 3 reasons to change…

You can make decisions based on the single responsibility principle. When you need to make a networking request, you can create a new class, because even though it’s needed to gather data for the report, it’s a different responsibility because it encapsulates a different kind of change.

The Single Responsibility Principle helps you define the boundaries of components. You can imagine that a smaller, simpler component is easier to maintain and debug. But what’s too small?

Likewise, some components get pretty big – lots of lines of code – but how do you know what’s too big? What’s a signal to move some of that code elsewhere? A heuristic to help with that, is the Single Responsibility Principle.

The single responsibility principle is valid for more things than just classes. Think about it:

• An app should solve one problem, and one problem only. Found a new problem? Build a new app.
• A code library should perform one task. Need another task done? Write a new library.
• A component should encapsulate one responsibility. Need the component to do more? Code a new component.

Even in life, it helps to only do one thing at a time…

Further Reading

So, now you know: the Single Responsibility Principle. Why don’t you start to apply it in your app projects? Think about your app’s architecture, it’s components and figure out if they follow the the SOLID principles.

Create Your App Now