Imagine that you are designing a house with You want to create a design that allows the owners to add new rooms or sections to the house, without having to demolish any existing walls or structures. modular architecture. To achieve this, you would need to design the house in such a way that it can easily accommodate new additions. You would need to plan and ensure that the existing structure is flexible enough to accommodate changes, without requiring any major modifications. Sounds too good to be true? well, it’s true. Welcome to the Open-Closed Principle. The principle The open-closed principle (OCP) of states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. object-oriented programming In simpler terms, it means that you should be able to add new features to your software without having to change the existing code that’s already working. That code will be left untouched. A good question to ask ourselves when implementing this principle will be: Will I need to modify the existing code when I will add a new functionality? But why? Why is it important that we will build our project using this principle? Well, there are several motives to use this principle: — As a project progresses, the codebase can become increasingly complex, making it challenging to maintain and add new functionality. If you’ve ever struggled to add new features to a project that has grown in complexity, you know firsthand how frustrating this can be. The open-close principle can keep your codebase stable and maintainable, even as your project evolves. Maintainability — By designing software components that are modular and easy to extend, we can reuse existing code to implement new features or functionality. This can save us time and effort, as we don’t need to start from scratch whenever we want to add something new to our software. Reusability Let’s try it Ok, let’s look at an example that violates the open-closed principle and analyze it: class PaymentService {
    constructor(amount, paymentProvider) {
        this.amount = amount
        this.paymentProvider = paymentProvider
    }

    makePayment() {
        switch (this.paymentProvider) {
            case 'credit':
                this.creditCardPayment()
                break
            case 'paypal':
                this.paypalPayment()
                break
        }
    }

    creditCardPayment() {
        console.log(`Performing credit payment of ${this.amount} dollars`)
    }

    paypalPayment() {
        console.log(`Performing paypal payment of ${this.amount} dollars`)
    }

} The problem with this code is that we have to make changes to the switch statement if we want to use another payment provider, like Stripe. Let’s see: class PaymentService {
    constructor(amount, paymentProvider) {
        this.amount = amount
        this.paymentProvider = paymentProvider
    }

    makePayment() {
        switch (this.paymentProvider) {
            case 'credit':
                this.creditCardPayment()
                break
            case 'paypal':
                this.paypalPayment()
                break
            // THIS PART IS NEW IN THE SWITCH STATEMENT
            case 'stripe':
                this.stripePayment()
                break
        }
    }

    creditCardPayment() {
        console.log(`Performing credit payment of ${this.amount} dollars`)
    }

    paypalPayment() {
        console.log(`Performing paypal payment of ${this.amount} dollars`)
    }

    stripePayment(){
        console.log(`Performing stripe payment of ${this.amount} dollars`)
    }

} So each time we add a new payment provider the switch statement will have to change, and we will violate the open-closed principle. How can we solve this issue? A good approach for implementing the open-closed principle is to use the Strategy design pattern. the Strategy pattern is a design pattern that lets you define a family of algorithms, encapsulate each one of them, and make them interchangeable. This way, you can switch the algorithm that you’re using at runtime, without having to change the context that uses it. This leads to more flexible and maintainable code. Let’s see it in action: First, we will create an interface or base class called that declares a method for making payments. This will serve as the strategy interface: PaymentProvider class PaymentProvider {
    makePayment(amount) {
        throw new Error('makePayment method must be implemented') // We throw an error so that we know we are not supposed to use this function, but override it instead
    }
} Next, we will separate classes for each payment provider that implements the interface and provide their implementation of the method: PaymentProvider makePayment class CreditCardPaymentProvider extends PaymentProvider {
    makePayment(amount) {
        console.log(`Performing credit payment of ${amount} dollars`)
    }
}

class PaypalPaymentProvider extends PaymentProvider {
    makePayment(amount) {
        console.log(`Performing PayPal payment of ${amount} dollars`)
    }
}

class StripePaymentProvider extends PaymentProvider {
    makePayment(amount) {
        console.log(`Performing Stripe payment of ${amount} dollars`)
    }
} Now, we will modify the class to accept an instance of during construction instead of a payment provider string: PaymentService PaymentProvider class PaymentService {
    constructor(amount, paymentProvider) {
        this.amount = amount
        this.paymentProvider = paymentProvider
    }

    makePayment() {
        this.paymentProvider.makePayment(this.amount)
    }
} Now we can add as many payment providers as we want, and we won’t need to change the existing code. Conclusion The Open-Closed Principle is a fundamental concept in SOLID programming that helps us write more robust and maintainable code. By understanding and applying this principle, we can build software that is more resilient to change and easier to manage. Happy coding :) Also published here.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Demystifying SOLID Programming (Part 1): Single Responsibility Principle

Nominated for 2022 - HackerNoon Contributor of the Year - Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Motivation

Nominated for 2022 - HackerNoon Contributor of the Year - Productivity

Nominated for 2022 - HackerNoon Contributor of the Year - Education

Too Long; Didn't Read

Make resilience your competitive advantage

Avoid Costly Technical Debt with the Open-Closed Principle

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Demystifying SOLID Programming (Part 1): Single Responsibility Principle

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

Demystifying SOLID Programming (Part 1): Single Responsibility Principle

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps