How does the Open/Closed Principle help a system support new behaviour without changing existing client logic?
Interview preparation resource from Gate Smashers.
The Open/Closed Principle helps by making client code depend on a stable abstraction rather than on specific implementations. To introduce new behaviour, add a new implementation, strategy, or decorator that satisfies the existing contract, then supply it through configuration, a factory, or dependency injection. The client continues to call the same abstraction, so its business logic does not need to change.
interface PaymentStrategy {
void pay(double amount);
}
class CreditCard implements PaymentStrategy {
public void pay(double amount) {
System.out.println("Paid " + amount + " with Credit Card");
}
}
class PayPal implements PaymentStrategy {
public void pay(double amount) {
System.out.println("Paid " + amount + " with PayPal");
}
}
// Client depends only on the abstraction.
class Checkout {
private final PaymentStrategy strategy;
Checkout(PaymentStrategy strategy) {
this.strategy = strategy;
}
void processOrder(double amount) {
strategy.pay(amount);
}
}
// New behavior added without modifying Checkout.
class Bitcoin implements PaymentStrategy {
public void pay(double amount) {
System.out.println("Paid " + amount + " with Bitcoin");
}
}
public class App {
public static void main(String[] args) {
// Composition chooses the behavior supplied to the client.
PaymentStrategy strategy = new Bitcoin();
Checkout checkout = new Checkout(strategy);
checkout.processOrder(250.0);
}
}Core idea
The Open/Closed Principle states that software entities should be open for extension and closed for modification. In practice, this means designing a stable extension point so that new behaviour can be introduced by adding code rather than repeatedly editing established client logic.
A module is not necessarily closed to every possible change. It is closed with respect to the variations anticipated by its abstraction or extension mechanism.
How the client remains unchanged
A client depends on an interface or abstract type that defines the operations it needs. It does not need to know which concrete class performs those operations.
When a new implementation conforms to the same contract, it can be substituted for an existing implementation. The client invokes the same methods, while the selected implementation provides different runtime behaviour.
- Abstraction: Defines the stable contract used by the client.
- New implementation: Adds behaviour by implementing the existing contract.
- Composition: Selects and supplies the implementation outside the client, for example through a factory or dependency injection.
Example
In the example, Checkout depends on PaymentStrategy. Adding Bitcoin creates another PaymentStrategy implementation, so Checkout does not need to be modified. The application composition code chooses whether Checkout receives CreditCard, PayPal, or Bitcoin.
Design considerations
OCP reduces the chance that a new variation will disturb stable client code, but it does not eliminate all changes. The composition layer may need to select or register the new implementation, and the abstraction itself may need revision if the new requirement cannot be expressed by the existing contract.
Abstractions should represent meaningful, likely points of variation. Creating interfaces or extension mechanisms for every small possibility can add unnecessary indirection and complexity.