SOLID: The Single Responsibility Principle

Written by Reinder de Vries on July 28 2020 in App Development

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

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!

  1. Single Responsibility Principle: Do One Thing Only
  2. A Practical Example of SRP
  3. What’s a Single Responsibility?
  4. Further Reading

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:

  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.

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

Get hired as an iOS developer

Learn to build iOS 14 apps with Swift 5

Sign up for my iOS development course, and learn how to start your career as a professional iOS developer.

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

Oops!

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.

Want to learn more? Check out these resources:

Reinder de Vries

Hi, I'm Reinder.
I help developers play with code.

Get the Weekly

Get iOS/Swift tutorials and insights in your inbox, every Monday.
  • This field is for validation purposes and should be left unchanged.

Most Popular

Browse Topics

Swift Sandbox

Code Swift right in your browser!
Go to the Swift Sandbox

Reinder de Vries

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.

×

Start your iOS career
Learn how in my free 7-day course

  • This field is for validation purposes and should be left unchanged.

No spam, ever. Unsubscribe anytime. Privacy Policy