Open/Closed Principle (OCP)

Definition

Software entities should be:

  • Open for extension
  • Closed for modification

👉 You should be able to add new functionality without changing existing code.


Purpose

  • Prevent breaking existing code
  • Improve scalability
  • Reduce bugs during changes
  • Make systems extensible
  • Follow clean architecture principles

Bad Example ❌


public class TaxCalculator
{
    public decimal Calculate(string type, decimal amount)
    {
        if(type == "GST")
        {
            return amount * 0.18m;
        }
        else if(type == "NoTax")
        {
            return 0;
        }

        return 0;
    }
}

Problem

Whenever new tax type comes:

  • InternationalTax
  • ServiceTax
  • ExportTax

👉 Existing code must be modified repeatedly.

This can:

  • Introduce bugs
  • Break old functionality
  • Increase complexity

Good Example ✅

Step 1: Abstraction


public interface ITaxStrategy
{
    decimal Calculate(decimal amount);
}

Step 2: Concrete Implementations

GST Tax


public class GstTax : ITaxStrategy
{
    public decimal Calculate(decimal amount)
    {
        return amount * 0.18m;
    }
}

No Tax


public class NoTax : ITaxStrategy
{
    public decimal Calculate(decimal amount)
    {
        return 0;
    }
}

International Tax


public class InternationalTax : ITaxStrategy
{
    public decimal Calculate(decimal amount)
    {
        return amount * 0.25m;
    }
}

Step 3: Use Abstraction


public class InvoiceService
{
    private readonly ITaxStrategy _taxStrategy;

    public InvoiceService(ITaxStrategy taxStrategy)
    {
        _taxStrategy = taxStrategy;
    }

    public decimal GetTotal(decimal amount)
    {
        return amount + _taxStrategy.Calculate(amount);
    }
}

Usage Example


var invoice =
    new InvoiceService(new GstTax());

Console.WriteLine(invoice.GetTotal(1000));

Output


1180

Key Concept

Instead of:

Modify existing if-else code

We do:

Add new strategy class

👉 Existing code remains untouched.


Real-Time Scenario

Payment System:

  • UPI Payment
  • Credit Card
  • Net Banking
  • Wallet Payment

👉 Add new payment methods without changing old code.


Advantages

  • ✔ Easier extension
  • ✔ Reduced bugs
  • ✔ Better scalability
  • ✔ Cleaner architecture
  • ✔ Safer code changes

Disadvantages

  • ✖ More interfaces/classes
  • ✖ Slight complexity increase
  • ✖ Over-engineering for small apps

When to Use

Use OCP when:

  • Business rules change frequently
  • New features added regularly
  • System needs scalability
  • Large if-else conditions appear

Real Project Mapping (.NET + Angular)

Feature OCP Usage
Payment providers OCP
Tax calculation OCP
Authentication methods OCP
File export formats OCP
Notification providers OCP

ASP.NET Core Real Example

Authentication providers:

  • JWT
  • Google
  • Facebook
  • OAuth

👉 New providers added without modifying framework core.


OCP vs SRP

OCP SRP
Extend without modification One responsibility
Focus on scalability Focus on responsibility
Avoid changing old code Avoid mixed responsibilities

Pro Tip

OCP works best with:

  • Strategy Pattern
  • Factory Pattern
  • Dependency Injection
  • Plugin architectures

Summary

OCP helps you:

  • Extend applications safely
  • Reduce modification risk
  • Build scalable systems

👉 Perfect for:

  • Enterprise applications
  • Payment systems
  • APIs
  • Plugin-based architectures

Comments

Popular posts from this blog

Promises in Angular

Debouncing & Throttling in RxJS: Optimizing API Calls and User Interactions

Csharp Coding - Session