В коде расчёта комиссии есть метод с цепочкой if по типу платежа, и при добавлении каждого нового способа оплаты приходится править этот метод и ещё три похожих. Какой принцип SOLID нарушен в первую очередь?
Open/Closed Principle: новое поведение требует правки существующего кода, а не добавления нового. Растущая цепочка if или switch по типу, повторённая в нескольких местах, — канонический признак.
- Лечение: интерфейс FeePolicy и реализация на каждый способ оплаты
- Выбор реализации — Map<Type, FeePolicy> или List<FeePolicy> из Spring
- Новый способ оплаты = новый класс, старый код не трогается
А ещё Один switch в фабрике допустим; плохо, когда он размножен по коду
Подробно
Растущий switch/if-else по типу — канонический признак нарушения OCP. Чинится полиморфизмом: интерфейс FeePolicy и по реализации на способ оплаты, выбор через Map или через внедрение List<FeePolicy> в Spring. Тогда новый способ оплаты — это новый бин, а старый код не трогается.
Что хотят услышать
- Принцип и признак нарушения.
- Решение через полиморфизм.
Частые ошибки
- Считать, что OCP запрещает править код вообще: закрываются от конкретной, уже проявившейся оси изменений.
- Выделять абстракцию на первом же варианте — до второго-третьего это спекулятивная общность.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Open/Closed Principle
- ✗Liskov Substitution Principle
- ✗Interface Segregation Principle
- ✗Single Responsibility Principle
Что спросят дальше
- Как sealed-иерархии из Java 17 сознательно меняют этот trade-off?
- Как OCP выглядит идиоматично в Spring?
Разбор темы
- SOLID: пять принципов дизайна
SRP, OCP, LSP, ISP, DIP — что каждая буква значит на самом деле, как выглядит нарушение в Java-коде, чем DIP отличается от DI и IoC.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.