Open-Closed Principle on iOS

In this video, we explore a practical application on the Open-Closed principle on iOS via an example with Firebase analytics. The Open-Closed principle is the 2nd principle in the SOLID principles by Uncle Bob and is designed to protect our code (close for modification) and yet allow for extension.
Source code
github.com/kel...
Buy me ☕️
www.buymeacoff...
If you benefited from this video, check out my detailed courses below
Master the skills to become a senior iOS developer
➡️ www.udemy.com/...
Build a Swift Package Manager library
➡️ www.udemy.com/...
Build a finance stocks app
➡️ www.udemy.com/...
Build a ToDoList app with Firebase
➡️ www.udemy.com/...
Send emails inApp with Sendgrid API
➡️ www.udemy.com/...
Build a weather app with Alamofire 5 and REST API
➡️ www.udemy.com/...
Build onboarding flows with Lottie animations
➡️ www.udemy.com/...
Build a basic onboarding flow for beginners
➡️ www.udemy.com/...

[@naqeeb_ahmed]

great. please make videos on other 4 as well.

[@abymathew575]

Nice explanation

[@kelvinfok]

Glad it helped!

[@YogeshPateliOS]

Hello Kelvin, thanks for the video. I understood the concept of Open Closed Principle. I have few questions 1. If I can make an extension of enum and add case for another button case so it violent the rule? 2. As you created struct rather then enum so in the future if I have scenrio to use cases so we have to struct for future modification rather then enum I am little bit confuse here. Waiting for your response and again thanks for the video 🙂

[@rpbrear]

Making an extension of an enum is fundamentally the same thing as adding a new case to the enum. In both scenarios you need to make a code change in order to be able to support logging a new analytic event type. What Kelvin has done is replace the enum with a struct that is inited with a string. This way you can add as many tracking events as you need without needing to modify a class (or in this case, an enum). That said, I think this video is a poor example of the O/C principle. See my comment on the main thread.

[@rpbrear]

I might be wrong but I think this is a really poor illustration of the O/C principle. Finding a way to prevent you having to change a class (by, in this case, swapping out an enum for strings!) is not the heart of the O/C principle. Which class in the demo is now OPEN FOR EXTENSION? The struct? Nope. What about the trackers? Well, in a sense the so-called 'closed' tracker was already open since adding a new enum case would not require a change to the tracker, but would still extend its functionality! All this demo illustrates is how to avoid making changes to a class by swapping out a safe implementation with one that will likely result in a bug. Analytic events are grouped by their event type (normally), but by removing the enum and replacing with a string (all in the name of O/C), Kelvin introduces an easy way to introduce bugs. Now when I track an event I need to MAKE SURE I enter the correct string for an event type to ensure they are correctly grouped. Enums prevent this error.