Unlocking the Power of SOLID Principles in Swift
SOLID Principles in Swift
Following SOLID Principles allows you to build better software
SOLID is a well known acronym created by Uncle Bob many years ago.
It’s a set of rules that will help you understand how good software should be crafted.
Conversely, if you follow SOLID and apply its principles, they will lead you to write better, more sustainable, extendable, understandable and testable code.
It’s relevancy in Swift and SwiftUI
What about iOS – iPad & Mac Apps or Mobile in General.
When we’re writing Apple Apps with Swift, or Objective-C for that matter, we are dealing with Software, and Software is meant to be Soft.
What I mean by soft is that we must be able to change it over time, extend it with easy and also be following the high standards in the Industry.
Following SOLID principles is no different in Mobile Development than in any other platform, is not just a thing for the Backend, or the Web.
The problem that I saw over the years on iOS Codebases is like if we were working on a silo from others IT departments, or at least nobody is going to look or take our code any further, or like “nobody cares” or the “just be simple” approach.
This approach lead us to places that we all know.
Places like the well know spaghetti code, the mess that can steal you hours from your life just to change the most simple and basic stuff.
I believe this happen because Mobile Development keeps being something “new” in the industry, and “major” devs are preoccupied with more known stuff and more “critical” code.
This of course is changing, and changing fast.
Businesses are understanding that Mobile Code is as critical as a backend or web code, and sometimes even more critical not only because it is the thing that user will hold in their hands, but because more and more Apps are being the stellar product, or the key thing; withouth the App, there is no busisness.
And this put us in a more relevant place, a more significant one in the IT department, and we should be up to the job and not just write “simple” “messy” code.
Our code, as Mobile devs, should be testable, extendable and easy to reason about like in any other platform.
SOLID Principles: One by One
An introduction to the principles
If we want to grow as developers, Swift Developers in our case, we should pay attention to this principles, learn about them and try to follow them as often as we can.
The SOLID Acronym stands for:
S – Single Responsibility Principle. (SRP)
O – Open/Closed Principle. (OCP)
L – Liskov Substitution Principle. (LSP)
I – Interface Segregation Principle. (ISP)
D – Dependency Inversion Principle. (DIP)
Single Responsibility Principle (SRP)
Let’s go deeper into each one
Single Responsibility Principle states that a module (a class or a method) should have only one reason to change.
This principle encourage the separation of concerns, where each module is responsible for a specific task.
By adhering to SRP, you can achieve code that is easier to understand, test, and maintain.
Separating functionality into smaller, focused classes enhances code reusability and reduces the impact of changes, as modifications will only affect the relevant class.
Very nice definition, if you have some experience as a developer in any platform you know that in real life this is a difficult task and in some codebases it’s even a dream to think about.
But it’s something that you must strive to get closer as you can get.
This means that you must think about this when you’re coding.
To help you figure out if you’re code is SRP compliant think in future changes about a piece of code.
If your class or method is creating something and at the same time is responsible for showing it on screen, or formatting it in some way, is probably doing more than one thing and, by definition, it’s reason to change may be more than one, making it a prime candidate to be divided into smaller well named functions.
Open-Closed Principle (OCP)
Open Closed Principle states that a module can be open for extension but closed for modifications.
This encourages you to think more in abstract terms when you’re designing your system.
In other words, code for abstractions and not code for hard implementations.
In Swift Development your abstract friend is a Protocol.
When you write a module that may receive an image to show in the screen try to think how many sources of images you may have? only one? or images can come from the network as well as from a camera or database?
When you start to think in more abstract ways you find yourself writing code that is easier to change.
Liskov Substitution Principle (LSP)
The Liskov Substitution Principle states that objects of a superclass should be able to be replaced by objects of it’s subclass without affecting the correctness of a program.
While this is something easily done with Swift in my opinion Swift is not meant to be used heavily on inheritance (hence a SubClass can inherit only from one SuperClass) and this can be better applied leveraging Protocols.
More on this later on.
Interface Segregation Principle (ISP)
The Interface Segregation Principle states that clients should depend only on interfaces (in our Swift case Protocols) that they require and not to adhere to interfaces that they don’t use.
Think of a Protocol with many methods.
The object that will adhere to this Protocol will use all of the methods or properties?
Did you recall that Protocol Conformance that end up with your class with many methods empty?
That’s where you need to start thinking on decoupling them into more than only one Protocol
Dependency Inversion Principle (DIP)
The Dependency Inversion Principle states that High Level modules should not depend on Low-Level ones.
This means that you must strive to separate your layers with abstractions, for us, Swift programmers, again with the use of Protocols.
For instance the Business Logic of your App should not depend on any UI element or Infrastructure Detail.
Conclusion
Applying SOLID principles to iOS development can greatly enhance the quality and maintainability of your apps.
By adhering to the Principles, you can create modular, scalable, and extensible codebases.
These principles encourage clean code design, improved testability, and better adaptability to ever changing requirements.
By investing time and effort in learning and applying SOLID principles, you can build robust iOS applications that are easier to understand, maintain, and evolve over time.
Thanks for reading!