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
- 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
Post a Comment