SOLID: Open Close Principle(OCP)

When a single change to a program results in a cascade of changes to modules using it, that sound like there is a “bad” design element, leading a program to become fragile, rigid, and un-reusable.

OCP attacks this in a very straightforward way.

An software entity should be open for an extension but close for the modification.

Means, It says that you should design modules that never change.When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works.

For example,

In the above example, If we change the CoreDataHelper with SQLDataHelper, UserManager is going to break because it has a tight coupling with CoreDataHelper.

Abstraction is the key

OCP promotes the use of the protocol/interface. Let’s solve the above example by adding an abstraction layer, let’s call it DataManager.

Here we have solved it using the Template Pattern but there are other patterns which can come to rescue for example

Decorator pattern, Factory Method, Strategy pattern etc.

The main essence of the OCP is the maintainable code, follow this rule, can surely help to reduce maintenance costs in future and the OPPOSITE also very true.

Another real world example we may have violated OCP could be, Using ENUMs for things which tend to be flexible or supposed to be changed.

Like using enum for FormInput types, for representing tabs,

And there are few screens using this (obv switch case), what happens if we introduce a new type ? This all occurrences going to break.

Rather we can do something like this,

There are so many built in iOS library follows the same

URLSessionComfiguration (default, ephermal), UILayoutPriority, MKDisplayPriority etc

Next is Liskov Substitution Principle

iOS Engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store