Что значит класс открыт для расширения?

Принцип Open/Closed из SOLID

"Класс открыт для расширения" — это один из ключевых принципов SOLID архитектуры (Open/Closed Principle). Это значит, что нужно иметь возможность добавлять новую функциональность без изменения существующего кода класса.

Что означает "открыт для расширения"?

Открытость для расширения означает, что поведение класса можно изменить через:

• Наследование (создание подклассов)
• Композицию (внедрение зависимостей)
• Полиморфизм (переопределение методов)

Что означает "закрыт для модификации"?

Закрытость для модификации означает, что мы не должны менять исходный код класса при добавлении новой функциональности.

Проблемный пример (нарушение принципа)

// ❌ ПЛОХО — класс не открыт для расширения
public class ReportGenerator {
    public void generate(String type) {
        if ("PDF".equals(type)) {
            generatePDF();
        } else if ("EXCEL".equals(type)) {
            generateExcel();
        } else if ("CSV".equals(type)) {
            generateCSV();
        }
        // Если добавить новый тип отчёта (JSON, XML),
        // нужно менять этот класс!
    }
    
    private void generatePDF() { /* ... */ }
    private void generateExcel() { /* ... */ }
    private void generateCSV() { /* ... */ }
}

Проблемы:

• Каждый новый тип требует изменения класса
• Риск нарушить существующий код
• Сложно тестировать каждый вариант
• Нарушает принцип Single Responsibility

Правильное решение (следование принципу)

// ✅ ХОРОШО — открыт для расширения, закрыт для модификации

// Абстракция (интерфейс) — основа расширяемости
public interface Report {
    void generate();
}

// Конкретные реализации
public class PDFReport implements Report {
    @Override
    public void generate() {
        System.out.println("Генерируем PDF отчёт");
        // PDF-специфичная логика
    }
}

public class ExcelReport implements Report {
    @Override
    public void generate() {
        System.out.println("Генерируем Excel отчёт");
        // Excel-специфичная логика
    }
}

public class CSVReport implements Report {
    @Override
    public void generate() {
        System.out.println("Генерируем CSV отчёт");
        // CSV-специфичная логика
    }
}

// Генератор отчётов (ЗАКРЫТ для модификации)
public class ReportGenerator {
    private Report report;
    
    // Внедрение зависимости — ключ к расширяемости
    public ReportGenerator(Report report) {
        this.report = report;
    }
    
    public void generate() {
        report.generate();
        // Эту строку никогда не нужно менять!
    }
}

// Использование
public static void main(String[] args) {
    // PDF
    ReportGenerator pdfGenerator = new ReportGenerator(new PDFReport());
    pdfGenerator.generate();
    
    // Excel
    ReportGenerator excelGenerator = new ReportGenerator(new ExcelReport());
    excelGenerator.generate();
    
    // Добавить JSON? Создаём новый класс JSONReport,
    // не трогаем ReportGenerator!
}

Как добавить новую функциональность

Теперь добавление нового типа отчёта не требует изменения существующего кода:

// НОВЫЙ отчёт — просто добавляем класс
public class JSONReport implements Report {
    @Override
    public void generate() {
        System.out.println("Генерируем JSON отчёт");
        // JSON-специфичная логика
    }
}

// ReportGenerator вообще не меняем!
// Просто используем новый класс:
ReportGenerator jsonGenerator = new ReportGenerator(new JSONReport());
jsonGenerator.generate();

Практический пример: система платежей

// Абстракция
public interface PaymentProcessor {
    void process(BigDecimal amount, String cardToken);
}

// Реализации
public class StripePaymentProcessor implements PaymentProcessor {
    @Override
    public void process(BigDecimal amount, String cardToken) {
        // Интеграция со Stripe API
        System.out.println("Обработка через Stripe: " + amount);
    }
}

public class PayPalPaymentProcessor implements PaymentProcessor {
    @Override
    public void process(BigDecimal amount, String cardToken) {
        // Интеграция с PayPal API
        System.out.println("Обработка через PayPal: " + amount);
    }
}

public class ApplePayPaymentProcessor implements PaymentProcessor {
    @Override
    public void process(BigDecimal amount, String cardToken) {
        // Интеграция с Apple Pay API
        System.out.println("Обработка через Apple Pay: " + amount);
    }
}

// Сервис платежей (не меняется)
@Service
public class PaymentService {
    private PaymentProcessor paymentProcessor;
    
    // Внедрение зависимости
    public PaymentService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }
    
    public void processPayment(BigDecimal amount, String cardToken) {
        // Этот код никогда не меняется!
        paymentProcessor.process(amount, cardToken);
        saveTransaction(amount);
        sendReceipt();
    }
    
    private void saveTransaction(BigDecimal amount) { /* ... */ }
    private void sendReceipt() { /* ... */ }
}

// Spring контроллер
@RestController
public class CheckoutController {
    @Autowired
    private PaymentService paymentService;
    
    @PostMapping("/checkout/stripe")
    public void stripeCheckout(CheckoutRequest request) {
        PaymentProcessor stripe = new StripePaymentProcessor();
        PaymentService service = new PaymentService(stripe);
        service.processPayment(request.getAmount(), request.getToken());
    }
    
    @PostMapping("/checkout/paypal")
    public void paypalCheckout(CheckoutRequest request) {
        PaymentProcessor paypal = new PayPalPaymentProcessor();
        PaymentService service = new PaymentService(paypal);
        service.processPayment(request.getAmount(), request.getToken());
    }
}

Factory Pattern — помощник Open/Closed

// Фабрика для создания нужного процессора
public class PaymentProcessorFactory {
    public static PaymentProcessor create(String provider) {
        return switch (provider) {
            case "stripe" -> new StripePaymentProcessor();
            case "paypal" -> new PayPalPaymentProcessor();
            case "apple" -> new ApplePayPaymentProcessor();
            default -> throw new IllegalArgumentException("Unknown provider");
        };
    }
}

// Теперь использование ещё проще
public void processPayment(String provider, BigDecimal amount, String token) {
    PaymentProcessor processor = PaymentProcessorFactory.create(provider);
    PaymentService service = new PaymentService(processor);
    service.processPayment(amount, token);
}

Spring и Open/Closed

Spring Framework идеально поддерживает этот принцип через Dependency Injection:

@Configuration
public class PaymentConfig {
    @Bean
    @ConditionalOnProperty(name = "payment.provider", havingValue = "stripe")
    public PaymentProcessor stripeProcessor() {
        return new StripePaymentProcessor();
    }
    
    @Bean
    @ConditionalOnProperty(name = "payment.provider", havingValue = "paypal")
    public PaymentProcessor paypalProcessor() {
        return new PayPalPaymentProcessor();
    }
}

// Сервис не зависит от конкретной реализации
@Service
public class OrderService {
    private final PaymentProcessor paymentProcessor;
    
    // Spring автоматически внедрит правильную реализацию
    public OrderService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }
    
    public void checkout(Order order) {
        paymentProcessor.process(order.getTotal(), order.getToken());
    }
}

Ключевые принципы

Используй абстракции (интерфейсы, абстрактные классы):

// ✅依赖于интерфейсе
public class Service {
    private PaymentProcessor processor;  // интерфейс
}

// ❌ Зависит от конкретного класса
public class Service {
    private StripePaymentProcessor processor;  // конкретный класс
}

Внедряй зависимости через конструктор:

// ✅ Хорошо
public MyClass(Dependency dep) {
    this.dep = dep;
}

// ❌ Плохо
public MyClass() {
    this.dep = new ConcreteDependency();  // жёсткая связь
}

Выводы

• Открыт для расширения — можно добавлять функциональность
• Закрыт для модификации — не меняем существующий код
• Используй интерфейсы — для определения контрактов
• Внедряй зависимости — через конструктор или Spring
• Это основа гибкой архитектуры — лёгко менять реализацию

Этот принцип — ключ к поддерживаемому и расширяемому коду!