Open/Closed

Software entities should be open for extension but closed for modification — add new behavior without changing existing, tested code.

The Problem

When new requirements are handled by editing existing classes — e.g., adding another `if` branch for each new type — every change risks breaking existing functionality and requires re-testing the whole class.

How It Works

›New behavior is added by creating new classes/implementations, not by editing existing ones
›Achieved through abstraction — interfaces or protocols that existing code depends on
›Existing, tested code remains untouched and stable
›Often realized via the Strategy pattern, polymorphism, or plugin architectures

When to Use

✓Systems that frequently need new variants (payment methods, file exporters, discount rules)

✓Avoiding long if/else or switch chains that grow with each new type

✓Designing plugin-based architectures

Real-World Examples

🍎

iOS

Adding a new UIView subclass without modifying UIKit itself

🤖

Android

Adding a new PaymentMethod implementation without touching the checkout flow

🌐

Web

Adding a new export format by implementing an Exporter interface

Code Examples

Swift

protocol DiscountStrategy {
    func apply(to price: Double) -> Double
}

struct NoDiscount: DiscountStrategy {
    func apply(to price: Double) -> Double { price }
}

struct PercentageDiscount: DiscountStrategy {
    let percent: Double
    func apply(to price: Double) -> Double { price * (1 - percent / 100) }
}

// New discount types are added without modifying PriceCalculator
struct PriceCalculator {
    let strategy: DiscountStrategy
    func finalPrice(for price: Double) -> Double {
        strategy.apply(to: price)
    }
}

let calculator = PriceCalculator(strategy: PercentageDiscount(percent: 20))
print(calculator.finalPrice(for: 100))  // 80.0