SOLID Principles for iOS developers

Aaina jain
Dec 27, 2018 · 2 min read

Embrace the principle, not an architecture

The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.

SOLID Principles is a coding standard for developing software in a proper way to avoid a bad design. It was promoted by Robert C Martin and is used across the object-oriented design spectrum. When applied properly it makes your code more extendable, maintainable, logical and easier to read.

What is principle in SOLID principles?

The SOLID principles are not rules, they are not laws and they are not perfect truths. This is a advice for a good software design which is not rigid and fragile.

Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

SOLID is a acronym for five design principles intended to make software designs more understandable, flexible and maintainable. SOLID principles were introduced by Martin in 2000.


You will come across two terms “rigidity” and “fragility” while reading about principles.

Let’s discuss what are they:

Rigidity: Software becomes difficult to change when changes causes other changes in dependent modules which are irrelevant. Simple changes become expensive.

Rigid code is the code that has dependencies that snake out in so many directions that you cannot make an isolated change without changing everything else around it.

— Robert Martin

For instance, you try to change some low-level detail in the data layer, and all of a sudden you get a compile error in the class that does the formatting for your View. If you often find yourself touching almost all the files of your project, whenever you make changes in a single class, it’s a symptom of rigid code.

Fragility: Fragile code is more worser than agile code as it doesn’t produce compile time error. Fixes introduce new bugs which contribute in regression issues.

Fragile code breaks in strange ways that you cannot predict.

— Robert Martin

Explaining principles here is too vast. I am going to dedicate individual posts for these principles.

S — Single Responsibility Principle

O — Open/Closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Thanks for reading article.

You can catch me at:

Linkedin: Aaina Jain

Twitter: __aainajain

Swift India

Aaina jain

Written by

Product Engineer📱at Go-Jek Tech, Organizer & Editor at Swift India

Swift India

Swift Developer Community in India 🇮🇳

More From Medium

More from Swift India

More from Swift India

Functional Swift: Closures { }


More from Swift India

More from Swift India

More from Swift India

Learn about Struct in Swift


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade