SOLID Principles in Swift

The goal of the principles is the creation of mid-level software structures that:

• Tolerate change

• Are easy to understand

• Are the basis of components that can be used in many software systems

SRP: The Single Responsibility Principle

Each software module has one, and only one, reason to change.

• OCP: The Open-Closed Principle

Software systems should be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

• LSP: The Liskov Substitution Principle

To build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.

• ISP: The Interface Segregation Principle

This principle advises software designers to avoid depending on things that they don’t use.

• DIP: The Dependency Inversion Principle

The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.

The Single Responsibility Principle (SRP)

A module should have one, and only one, reason to change.

When we create a class, we should ask ourselves how many responsibilities does this class have.

Let’s see in this example

In this class above, the class CardsHandler has too many responsibilities, including making a network call, parsing the data, saving the data to the database. Clearly, this class has too many reasons to change.

We should design the classes in such a way that they are having only a single responsibility and single reason for change. Let’s see how we can fix this problem.

This principle helps the classes to be much cleaner and much more independent of each other, so it’s easier to modify only the needed classes.

In earlier example we would also not be able to test the important functions because they are private. But in the SRP solution we can easily test all the classes.

The Open Closed Principle (OCP)

A software artifact should be open for extension but closed for modification.

It should be easy to add new features to the class.

If you want to create a class easy to maintain, it must have two important characteristics:

• Open for extension: You should be able to extend or change the behaviours of a class without efforts.
• Closed for modification: You must extend a class without changing the implementation.

Lets see an example below.

The Liskov Substitution Principle (LSP)

LSP states that any class should be able to be replaced by one of its subclasses without affecting its functioning.

We must make sure that new derived classes should extend the base classes without changing the base class behavior

A subclass should override the parent class methods in a way that it doesnt break the funtionality of base class from user’s perspective.

It’s important that the main implementation does not contain the logic.

Lets see an example below.

The Interface Segregation Principle

ISP States that a software system must make fine grained interfaces that are specific to client requirements. This provide flexibility and thin interfaces that can be reused in multiple places

A common problem in Object Oriented Programming are interfaces that contain more information than required. This is a concept known as FAT (bloated) interfaces. The ISP principle helps solve this issue.

Let’s go over below example to see what I mean.

The Dependency Inversion Principle

DIP state that high level modules should not depend on low level modules. Both should depend upon abstractions.

Abstractions should not depend upon details, details should depend upon abstractions.

DI provides Testability, Loose Coupling, Flexibility and Scalability. Lets see an example below.

Summary

If you follow along all the principles, we can see that we can solve most of the issues by following protocol oriented programming. These principles can make your product more maintaianble, reusable, scalable and testable.

Let’s think about SOLID when writing code to develop a quality software.