Open Closed Principle
Tags: solid, ocp, reusability, openclosed
Published: 2021-03-30 14:17:33

---
title: Open Closed Principle
published: true
description: open closed principle
tags: solid, ocp, reusability, openclosed
---

# Open Closed Principle

The open-closed principle says that a class should be opened for extension and closed for modification. What does that mean? 

A class should be made easy to add features and hard to alter its core function.

Suppose that you need to write a password validator for a user creation flow. You already have a `CreateUser` class. What can you do?

You can create a password validation method inside the `CreateUser` class, but that would violate the Single Responsibility principle. You should separate the validation responsibility from the `CreateUser` class. You can create a `ValidatePassword` class to accomplish this. Great, that should do it!

However, a `ValidatePassword` class is not really that flexible. This class can only validate a password input. An even more flexible solution would be to create a `Validate` class with a `password` method inside it. In the future, if you need to add more validation logic, you can just extend this `Validate` class with more methods like `email` and `username` to validate user email and username!

Let's imagine what would have happened if you had created `ValidatePassword`. In the future if you need to validate email and username, you will have to create `ValidateEmail` and `ValidateUsername` classes. I will bet you two boxes of donuts that there will be plenty of duplicate codes (`ValidateEmail`, `ValidateUsername`, and `ValidatePassword` mostly do the same thing).

I understand that upcoming features are often unprecedented. Some classes are more subtle and harder to spot for reusability. Maybe the PM assured you last month that the only validation you would ever need was `ValidatePassword`, so you created that class naively believing that there was no need to extend it in the future. However, this week your PM told you that you needed to validate email and username after all! No worries, as long as you catch them early on, you could easily abstract it and create the `Validate` class.

This is the "open" part of the open-closed principle: the `Validate` class is open for extension. Each time you need to extend the feature, just add a new interface. Need an email validation? Add an email interface. Need a username validation? Add a username interface.

What about the "closed" part of the open-closed principle? By definition, a class is closed. In practice, you would create an instance of that class object, something like `passwordValidator = new Validate("password")`. 

Once a class is defined, no one should alter it. The `Validate` class validates different attributes. That's it. If you decided that the `Validate` class should start saving password into the database, then you violated the "closed" part (you also violated the single-responsibility principle).

By keeping the open-closed principle, anyone who depends on `passwordValidator` won't receive surprise bugs.

Anytime you start thinking, "Hey, I've written codes like this before...", it's a good chance that you can create an extensible, more abstract class.