The Single Responsibility Principle

Written by Reinder de Vries on January 2 2018 in App Development

The Single Responsibility Principle

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.

Much 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.

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!

Learn how to build iOS apps

Get started with iOS 11 and Swift 4

Sign up for our iOS development course Zero to App Store and learn how to build professional iOS 11 apps with Swift 4 and Xcode 9.

Do One Thing Only

The first principle of SOLID is the Single Responsibility Principle (SRP). I’ve roughly translated it 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 performs a function. The single responsibility principle states that a class should only have one reason to change.

In reality, this means two things:

  1. A class should only do one thing
  2. 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.

A Practical Example: Creating Reports

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 grades, productivity, incoming emails or tweets you sent on Twitter.

You could create a class ReportGenerator in your app. It takes the data for the report, then 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:

  • Gather data for the report
  • Create the report formatting
  • Export the report

Oops!

What Is 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 then break it up in multiple classes?

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.

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 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 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.

Want to learn more? Check out these resources:

Enjoyed this article? Share it with another developer! (They’ll thank you for it.)

Reinder de Vries

Reinder de Vries is a professional iOS developer. He teaches app developers how to build their own apps at LearnAppMaking.com. Since 2009 he has developed a few dozen apps for iOS, worked for global brands and lead development at several startups. When he’s not coding, he enjoys strong espresso and traveling.

Leave a Reply

Required to post: Your real name and email address, and a pleasant demeanor. Your email address will not be published. Markdown is supported.