© 2026 Patryk Sobiło – programming, implementations, travels

Open/Closed Principle

admin - 2 July 2026 - 12:31 pm

Open for Extension, Closed for Modification

Definition

The Open/Closed Principle (OCP) states that software entities (such as classes, modules, or functions) should be open for extension but closed for modification.

In other words:

  • we should be able to add new functionality,
  • we should avoid modifying existing, working code.

Simply put:

Want to add a new feature? Write new code instead of changing code that already works and has been tested.

This means that the behavior of a class can be extended (new capabilities can be added) without having to open it up and modify its existing implementation.

Real-Life Example: How to Understand It?

Imagine a multifunctional kitchen appliance.

When you buy it, you get a base unit with a motor and a set of attachments designed for different tasks (a chopping blade, a whisk, etc.).

After some time, you decide that you would like to use the same appliance to juice fruits. You notice that you do not have the appropriate attachment, so you consider grabbing a screwdriver, opening the housing, accessing the motor, removing some screws, and installing new components yourself.

Is this approach safe?

Definitely not. In fact, it is unlikely to work because you could damage the motor and cause the appliance to stop functioning altogether.

If we want to make juice using the same appliance, we simply go to the store and buy the correct attachment that is designed for that purpose and compatible with the appliance’s base unit.

The base of the kitchen appliance is closed for modification (we do not tamper with the motor), but the overall system is open for extension (we can purchase many attachments for different purposes).

Software should work in exactly the same way.

The core mechanism of our application should be like the base of the kitchen appliance—stable and untouched—while new features should be like interchangeable attachments.

Example — OCP Violation

Suppose we are building a payment processing system for an online store.

Initially, we support only traditional bank transfers and credit/debit card payments.

The PaymentProcessor class below violates OCP:

class PaymentProcessor {
 
    public void processPayment(String method, double amount) {
        if (method.equalsIgnoreCase(“CARD”)) {
            // Card authorization and charging logic
            System.out.println(“Paying by card: ” + amount + ” PLN”);
 
        } else if (method.equalsIgnoreCase(“TRANSFER”)) {
            // Bank transfer processing logic
            System.out.println(“Paying by bank transfer: ” + amount + ” PLN”);
        }
    }
}

The problem appears when the business asks us to add a new payment method, such as BLIK or PayPal.

To do that, we must:

  1. Open the PaymentProcessor class.
  2. Add another else if block.

Why Is This Bad?

The class is open for modification.

Every time we add a new payment method, we modify the same file. While adding BLIK support, we could accidentally introduce a typo or bug that breaks card payments that have been working perfectly for months.

Example — OCP-Compliant Design

To fix this code, we need to create a universal socket (an interface) and interchangeable attachments (classes implementing specific payment methods).

Create a Universal Socket (Interface)

interface PaymentMethod {
    void pay(double amount);
}

Create Interchangeable Attachments (Implementations)

class CardPayment implements PaymentMethod {
 
    public void pay(double amount) {
        // Card payment logic
        System.out.println(“Paying by card: ” + amount + ” PLN”);
    }
}
 
class TransferPayment implements PaymentMethod {
 
    public void pay(double amount) {
        // Bank transfer logic
        System.out.println(“Paying by bank transfer: ” + amount + ” PLN”);
    }
}

Create a Managing Class — Closed for Modification

lass PaymentProcessor {
 
    public void process(PaymentMethod paymentMethod, double amount) {
        // This class does not know and does not need to know
        // how a particular payment method works.
        // It simply calls pay().
        paymentMethod.pay(amount);
    }
}

What Do We Gain?

Now, if we want to add BLIK payments, we do not touch a single line of code in PaymentProcessor.

We simply create a brand-new class:

class BlikPayment implements PaymentMethod {
 
    public void pay(double amount) {
        // BLIK payment logic
        System.out.println(“Paying with BLIK: ” + amount + ” PLN”);
    }
}

The system has been extended, yet no existing code has been modified.

The Open/Closed Principle has been satisfied.

Why Is OCP Important?

Peace of Mind and Safety

We do not touch code that is already running in production and generating business value.

This significantly reduces the risk of breaking existing functionality when adding new features.

Less Regression Testing

Testers do not have to re-test the entire payment system.

They only need to test the newly added class (for example, BlikPayment).

Better Team Collaboration

If five developers need to add five different payment methods, each developer can work on their own file.

They do not interfere with one another and create fewer merge conflicts in version control systems such as Git.

Cleaner and More Readable Code

Instead of having one enormous method filled with dozens of if-else statements, we end up with small, focused, and easy-to-understand classes.

When Should You Apply OCP?

Apply OCP when:

  • you notice repeated if-else or switch statements that check an object’s “type” and make decisions based on it;
  • you know that a business requirement will regularly grow with new variants (for example, additional report formats such as PDF, Excel, or CSV; new country-specific tax rules; or new shipping methods);
  • you are building a plugin-based architecture where users of your code should be able to add their own extensions.

Design your code as if tomorrow a client might ask for a feature that nobody has thought about today.

CATEGORIES:

SOLID Principles
Previous
Next

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *

Latest Comments

No comments to show.

© 2026 Patryk Sobiło – programming, implementations, travels. Created with ❤ using WordPress and Kubio