iOS Best Practices. Part 4: S.O.L.I.D.

As a continuation of Part 3: Architecture

Let’s talk about S.O.L.I.D. principles and how they can be applied in Swift.

SThe Single Responsibility Principle

Too strong class

S.O.L.I.D. SWIFT

This class works with logic, makes network requests and does navigation work.
So, let’s simplify it and rework it using The Single Responsibility Principle.

S.O.L.I.D.

OOpen-Closed Principle (OCP)

It’s a principle for object-oriented design first described by Bertrand Meyer that says that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.

Firstcreate protocol abstractions,
Then
create final implementation,
Do
extensions,
Do not do
changes.

SWIFT S.O.L.I.D.

LLiskov Substitution Principle (LSP)

Derived classes must be substitutable for their base classes.

swift s.o.l.i.d.

IInterface Segregation Principle (ISP)

Make simple abstractions that clients need.

S.O.L.I.D. principles

DDependency Inversion Principle

Depend on abstractions, not on specific classes/structures.

Swift SOLID

Abstractions Everywhere! Remember it!

This was a brief guide about S.O.L.I.D. practice in Swift code.

Read moreiOS Best Practices. Part 2: Swift Code Style >>>


Maxim Vialykhvialyx is CactusSoft iOS Tech Lead.

Technical Background
Programming languages: Swift, Objective-C, Java
Technologies and Platforms: iOS, Android, Windows Phone, Amazon S3, Google Cloud, Google APIs, Facebook APIs
Frameworks: PhoneGap, Xamarin
Tools: Invision, SVN, Git, PhoneGap, Titanium, Xamarin, Sketch, xCode, IntelliJ IDEA

Share this page
If there is a project needing help or even a skill set you are missing, contact us.
Subscribe To Our Newsletter
To get new inspiring articles and news right in your inbox.