Что такое принципы SOLID и как они помогают писать структурированный код

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

Понимаете ли вы смысл принципов, а не расшифровку аббревиатуры. Сильный ответ содержит пример нарушения из своего опыта.

Как отвечать

Пять принципов, и у каждого одна главная мысль.

Единственная ответственность. У класса одна причина для изменения. Класс, который и считает зарплату, и рисует отчёт, и шлёт письмо, придётся править при изменении любой из трёх вещей.

Открытость и закрытость. Новое поведение добавляется расширением, а не правкой существующего кода. Признак нарушения: длинный switch по типу, куда дописывается ветка на каждый новый случай.

Подстановка Лисков. Наследник должен работать везде, где работает базовый тип, не ломая ожиданий. Классический контрпример: Square наследует Rectangle и ломает код, который меняет ширину и высоту независимо.

Разделение интерфейсов. Лучше несколько узких интерфейсов, чем один широкий: иначе реализация вынуждена определять методы, которые ей не нужны, и они заполняются заглушками.

Инверсия зависимостей. Модули зависят от абстракций, а не от конкретных реализаций. Сервис принимает интерфейс хранилища, а не конкретный класс работы с PostgreSQL, и потому тестируется без базы.

Общая польза: код проще менять по частям и проще тестировать, потому что зависимости явные и подменяемые.

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

Пересказывают расшифровку буквами, но не могут привести пример нарушения.

Понимают единственную ответственность как «один метод в классе». Речь про причину изменения, а не про размер.

Доводят принципы до абсурда: интерфейс на каждый класс и пять слоёв абстракции ради одной реализации. Стоит прямо сказать, что это инструменты, а не догма, и в маленьком модуле они часто избыточны.