Single Responsibility Principle in Swift
Do yourself a SOLID
SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable. Now applying them to Swift can be a little tricky, and this article has been written to make the Single Responsibility Principle easy to understand for new Swift Programmers.
This article also has a supporting YouTube video: https://youtu.be/e5ne2xnlMuI
Solid.
Difficulty: Beginner | Easy | Normal | Challenging
Terminology
Class: An object that defines properties and methods in common
Single Responsibility Principle: every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function
SOLID: a mnemonic acronym for five design principles intended to make software designs more understandable
The Single Responsibility Principle (SRP)
A class should only have a single reason to change.
In other words that means the following:
- A particular class should only do one thing
- There should only ever be a single reason to change a certain class
So each class is restricted to doing one thing.
It is tempting for Swift programmers to overload responsibilities into a view controller.
This is partly to do with the basic architecture pattern encourged for our use by Apple — the MCV pattern.
The difficulties in SRP — MVC
The most common basic diagram for MVC (Model View Controller) is below
That is, we can separate out the use of controllers and models so the controller communicates with the model in a two-way relationship
and the controller also has a relationship with the view
Now the issue is that the view controller is both a view and a controller (which would explain the name)!
The secondary issue is that many programmers also cram the model into the view controller, and this is a recipe for disaster.
It also means that many developers kind of discount the Single Responsibility Principle when coding in Swift.
This is a bad habit. Let us break this out into an easy example
The example bad class
A view controller typically will have a data source, and this if frequently defined in the ViewController. Now saying that this is a bad class is a little strong, but equally it does break the Single Responsibility Principle (Even though the data source has been placed nicely into an extension).
I’ll say it again (ignore the subtitle) — that this isn’t necessary bad…but there you go…
Following the Single Responsibility Principle
We can create the DataSource as a different class. No problem.
Yes, of course (if you’re looking through the repo version) you would want DataSource in a different file. With a different name. But there’s always improvements that can be made — the point is that we’ve got the data out of that view controller.
Conclusion:
SOILD is a collection of principles that can actually help with your coding standards, and making sure that your code is maintainable and — well of good quality.
Does that make sense? I hope so. Want to read more about the SOLID principles, perhaps you might like to read an article about that. I hope that helps you.
Any questions? You can get in touch with me here
