Какие принципы SOLID нарушаются при обработке разных типов документов в одном методе

Что проверяют

Умеете ли вы увидеть проблему в конкретном коде, а не перечислить пять букв. Обычно показывают метод со switch или цепочкой instanceof на десяток веток и спрашивают, как бы вы его переписали и что от этого станет лучше.

Как отвечать

Начните с двух принципов, которые нарушаются всегда:

• SRP: у метода столько причин меняться, сколько типов документов. Правка логики счёта трогает тот же код, что обрабатывает договор, и тесты на один тип ломаются из-за другого;
• OCP: чтобы добавить новый тип, приходится открывать и править существующий метод, а не дописывать новый класс.

Дальше по ситуации. Если внутри есть instanceof и приведение к наследнику, общая абстракция Document не даёт нужного поведения, и разговор выходит на LSP. Если метод сам создаёт new PdfParser() и new XmlParser(), нарушен DIP: верхний уровень зависит от конкретных классов, а не от интерфейсов. ISP сюда притягивать не нужно, он про толстые интерфейсы, а не про длинные методы.

Каркас рефакторинга:

• интерфейс DocumentHandler с методами DocumentType type() и void handle(Document doc);
• по классу на тип документа, каждый со своими тестами;
• реестр обработчиков: в Spring достаточно внедрить List<DocumentHandler> и собрать из него Map<DocumentType, DocumentHandler> при старте.

Это паттерн «Стратегия». Сильный ход: упомянуть альтернативу из современной Java. Если набор типов закрыт и меняется редко, sealed interface Document плюс switch с сопоставлением по типу (финальная версия в Java 21) даёт проверку полноты на этапе компиляции: забытая ветка просто не соберётся.

Где спотыкаются

Называют все пять принципов подряд, чтобы наверняка. Интервьюер спросит, как именно здесь нарушен ISP, и ответа не будет.

Предлагают вынести ветки в приватные методы того же класса. Метод стал короче, но класс по-прежнему меняется при каждом новом типе, и OCP нарушен так же.

Не называют цену решения. Стратегия оправдана, когда типов много и их число растёт. Для двух стабильных типов простой switch читается лучше, чем пять новых классов и фабрика.