Классы и модули должны быть **открыты для расширения, но закрыты для модификации**. Это означает, что функциональность можно добавлять без изменения существующего кода. Такой подход позволяет минимизировать риск возникновения ошибок в уже работающей системе при внедрении новых функций. **Принцип открытости/закрытости (Open-Closed Principle, OCP)** является вторым из пяти [[SOLID]]-принципов и способствует созданию гибкой и поддерживаемой архитектуры.
1.**Гибкость кода:** Добавление нового функционала не требует изменений существующего кода, что снижает риск ошибок.
2.**Улучшенная тестируемость:** Изолированные реализации проще тестировать независимо друг от друга.
3.**Снижение связанности:** Код становится более модульным, и изменения в одной части системы не затрагивают другие.
4.**Поддерживаемость:** Разработчики могут легко добавлять новые возможности без угрозы сломать существующий функционал.
## Пример нарушения OCP
Рассмотрим класс, который обрабатывает оплату, поддерживая только один способ оплаты через кредитную карту:
```java
public class PaymentProcessor {
public void processPayment(String type, double amount) {
if (type.equals("credit_card")) {
// Логика оплаты через кредитную карту
}
}
}
```
Если требуется добавить поддержку нового способа оплаты, например, PayPal, придется модифицировать метод `processPayment`:
```java
public class PaymentProcessor {
public void processPayment(String type, double amount) {
if (type.equals("credit_card")) {
// Логика оплаты через кредитную карту
} else if (type.equals("paypal")) {
// Логика оплаты через PayPal
}
}
}
```
Такой подход нарушает OCP, так как для добавления нового функционала приходится изменять уже существующий код. Это увеличивает риск ошибок и затрудняет сопровождение.
Используем интерфейсы для реализации разных способов оплаты:
