Open Closed Principle Explained - SOLID Design Principles | Example Java Code Demo | InterviewDOT
Channel: Interview DOT
Date: 2020-03-24

Click here - https://www.youtube.com/channel/UCd0U_xlQxdZynq09knDszXA?sub_confirmation=1 to get notifications.

Tamil Open Closed Principle Explained - SOLID Design Principles | InterviewDOT

What is the Open/Closed Principle?
Let’s begin with a short summary of what the Open/Closed Principle is. 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”.

At first thought that might sound quite academic and abstract. What it means though is that we should strive to write code that doesn’t have to be changed every time the requirements change

Open Closed Principle
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
The main idea behind this one is that in one part of your code, you have your abstractions such as classes, modules, higher order functions that do one thing and do it well. You want to keep them pretty, cohesive and well behaved.
On the other hand, you have changing requirements, scope changes, new feature requests and business needs. You cannot keep your precious abstractions in a pristine form for a long time. Inevitably you will have to add more functionality or add more logic and interactions. You want to have a way of adding that extra scope while keeping the code in good standing.
That’s where this particular principle of Open Closed comes in play to help formulate a way to do that nicely. When the time comes, where you have to modify existing code you need to make sure that you:
Keep the current functions, Classes, modules as they are or at least close to what they used to be — aka immutable.
Extend, in a composable (avoid inheritance) way the existing Classes, functions or modules so that they expose the new feature or functionality possibly in a different name.
I make a good note to try to avoid classical inheritance here as it tends to couple things in a bad way. Use Classical inheritance for well-defined structures while trying to avoid misuse.

The Open-Closed Principle (OCP) states that software entities (classes, modules, methods, etc.) OpenClosedPrincipleshould be open for extension, but closed for modification.

In practice, this means creating software entities whose behavior can be changed without the need to edit and recompile the code itself. The simplest way to demonstrate this principle is to consider a method that does one thing. Let’s say it writes to a particular file, the name of which is hard-coded into the method. If the requirements change, and the filename now needs to be different in certain situations, we must open up the method to change the filename. If, on the other hand, the filename had been passed in as a parameter, we would be able to modify the behavior of this method without changing its source, keeping it closed to modification.

The Open-Closed Principle can also be achieved in many other ways, including through the use of inheritance or through compositional design patterns like the Strategy pattern.