Unlocking the Power of SOLID Principles in Swift

Posted on by Fernando Putallaz

As you may know, and if you don’t please keep reading, following SOLID Principles allows you to build better software.

But what about applying them when you’re developing Apps with Apple Swift Programming Language for iOS, MacOS, TVoS, WatchOS or even with the newest VisionOS?

Well, here is an introduction of the principles and its application when developing for Apple Platforms with Swift.

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)

Let’s go deeper into each one.

Single Responsibility Principle (SRP)

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

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 a from the camera?

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? If it’s not the case you should split your Protocol into many.

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 the 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 changing requirements. By investing time and effort in applying SOLID principles, you can build robust iOS applications that are easier to understand, maintain, and evolve over time.

Next:

Coding examples applying SOLID.

Stay tuned.