Open-Closed Principle (OCP)

Usage

📝 Guideline

Open-Closed Principle: Classes should be closed for modification but open for extension.

The Open-Closed Principle dictates that you shouldn't need to change existing code to add more functionality to a class. Instead, you should be able to extend its behavior without modifying its implementation.

🛠️ How to Apply

Abstraction: Abstract classes and interfaces can define a common contract for different implementations, allowing new functionality to be added by implementing these abstractions. 🔑
Inheritance: Use inheritance to create specialized classes that extend a base class, enabling additional functionality to be added without modifying the existing code. 🧬
Polymorphism: Utilize polymorphism to accept different implementations of a common interface, promoting extensibility. 🔀
Composition: Exctend objects using composition rather than modifying existing classes directly, allowing new behavior to be added by combining different components. 🔧
Dependency Injection: Inject dependencies into classes to allow for flexible component replacement and avoid hard dependencies. 💉

Pros and Cons

👍 Pros

Enhanced Modularity: Promotes modularity by containing changes within specific classes or modules, reducing the impact on other parts of the codebase. 🧩
Maintainability: The principle promotes a design that minimizes modifications to existing code, making it easier to maintain and reducing the risk of introducing bugs. 🛠️
Reusability: By following the Open-Closed Principle, code becomes more reusable as new functionality can be added by extending existing classes or implementing abstractions. ♻️

👎 Cons

Increased Complexity: Adhering to the Open-Closed Principle may introduce additional layers of abstraction and complexity, which can be challenging to manage in certain scenarios. 🤔
Potential Overengineering: Applying the principle too rigidly can lead to over-engineering, resulting in unnecessary abstractions and reduced development speed. 🚧

Examples

❌ Bad

class Order {
  // ...
 
  calculateTotal() {
    // calculate total order cost
  }
 
  applyDiscount() {
    // apply discount based on user type
  }
 
  generateInvoice() {
    // generate invoice for the order
  }
}

✅ Good

interface Order {
  calculateTotal(): number
}
 
class RegularOrder implements Order {
  calculateTotal() {
    // calculate total order cost
  }
}
 
class DiscountedOrder implements Order {
  calculateTotal() {
    // calculate total order cost with discount
  }
}
 
class OrderInvoice {
  generate(order: Order) {
    // generate invoice for the order
  }
}

References

🧱 SOLID Principles

SOLID is an acronym for five other class-design principles:

Single Responsibility Principle: Encourages classes to have a single responsibility, aligning with the Open-Closed Principle for better code maintainability. 🎯
Liskov Substitution Principle: Focuses on substitutability, supporting the Open-Closed Principle by allowing seamless extension with subclass objects. 🔄
Interface Segregation Principle: Suggests smaller and more focused interfaces, complementing the Open-Closed Principle's emphasis on abstraction and extension. 📦
Dependency Inversion Principle: Promotes depending on abstractions, aligning with the Open-Closed Principle's goal of extending functionality without modifying existing code. 🔧
Don't Repeat Yourself (DRY): DRY principle reduces code duplication, helping adhere to the Open-Closed Principle by minimizing unnecessary modifications. ♻️