Mastering the Open-Closed Principle: Build Extendable and Stable Code

Created at 2025-09-17 Updated at 2026-02-17 - 4 min. read Tag open-closed-principle / solid / software-design / clean-code / design-patterns

Understanding the Open-Closed Principle (OCP) in Software Design

The Open-Closed Principle (OCP) is one of the five SOLID principles of object-oriented design that guide developers to write code that is maintainable, extensible, and robust. Coined by Bertrand Meyer in 1988 and popularized by Robert C. Martin (Uncle Bob), the principle states:

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

This means you should be able to add new functionality to existing code without changing its existing source code.

Why Is the Open-Closed Principle Important?

When software systems grow, requirements change and new features are added. Without OCP, developers often modify existing code, which can introduce bugs and break tested functionality. The OCP promotes:

• Extensibility: Add new behaviors via new code, not by changing existing.
• Robustness: Existing code remains untouched, reducing bugs.
• Maintainability: Easier to understand and evolve code.
• Scalability: Systems grow naturally without fragile dependencies.

Implementing OCP with Abstraction and Polymorphism

You typically implement OCP by coding against abstractions rather than concrete implementations. This means using interfaces or base classes defining contracts and extending these with new classes:

1
2
3
4
5
6
7
8
9
10

# Notification System with Polymorphism in JavaScript

## 1. Abstract Class

```js
class Notification {
  send(message) {
    throw new Error('Method "send" should be implemented');
  }
}

• Defines a common contract (send) for all notification types.
• Any subclass must implement the send method.

2. Concrete Classes

1
2
3
4
5
6
7
8
9
10
11

class EmailNotification extends Notification {
  send(message) {
    console.log(`Sending email notification: ${message}`);
  }
}

class SMSNotification extends Notification {
  send(message) {
    console.log(`Sending SMS notification: ${message}`);
  }
}

• EmailNotification and SMSNotification both implement the send method.
• New notification types can be added without modifying existing ones (Open/Closed Principle).

3. Processor (Context Class)

1
2
3
4
5
6
7
8
9

class NotificationProcessor {
  constructor(notification) {
    this.notification = notification;
  }

  notify(message) {
    this.notification.send(message);
  }
}

• Works with any notification type through polymorphism.
• NotificationProcessor doesn’t care if the notification is Email, SMS, Push, etc.
• Delegates the responsibility of sending to the chosen strategy.

4. Usage Example

1
2
3
4
5

const emailProcessor = new NotificationProcessor(new EmailNotification());
const smsProcessor = new NotificationProcessor(new SMSNotification());

emailProcessor.notify("Hello via Email!");
smsProcessor.notify("Hello via SMS!");

✅ Output

1
2

Sending email notification: Hello via Email!
Sending SMS notification: Hello via SMS!

🔹 Benefits

• Extensible → Add new types (Push, WhatsApp, Slack, etc.) without changing existing code.
• Polymorphic → Processor code stays the same regardless of notification type.
• Clean separation → Processor only handles when to notify, while notification classes handle how.

Explanation

• Notification is a base class with an abstract send method.
• EmailNotification and SMSNotification extend the base, implementing send.
• When a new notification type is needed, create a new class without changing existing ones.
• NotificationProcessor works with any Notification object, making the system open to extension but closed to modification.

Benefits of Applying OCP

• Reduces regression bugs by not modifying existing tested code.
• Encourages loosely coupled systems via abstractions.
• Simplifies testing since components are isolated.
• Supports agile development by allowing incremental feature additions.

Challenges

• Designing good abstractions upfront requires experience.
• Risk of over-engineering if abstractions are added unnecessarily.
• May introduce minor performance overhead due to indirection.

Conclusion

The Open-Closed Principle helps create software that is easier to maintain and extend over time. Writing code that is open for extension but closed for modification ensures stability and flexibility, leading to higher quality codebases and more efficient development workflows.

References:

• Bertrand Meyer, Object-Oriented Software Construction (1988)
• Robert C. Martin, Clean Architecture (2017)
• SOLID Principles Overview, FreeCodeCamp, GeeksforGeeks