Что хотят услышать интервьюеры:

Принцип S в SOLID — это Single Responsibility Principle: у класса должна быть одна причина для изменения. Обычно хотят услышать, что класс не должен одновременно хранить бизнес-логику, работать с БД, логировать и форматировать вывод. Хороший ответ — показать, как разделение ответственности упрощает поддержку и тестирование.

Определение:

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

Пример использования:

Допустим, есть класс Report, который одновременно рассчитывает данные отчёта и сохраняет его в файл. Это нарушение SRP, потому что изменение формата сохранения не должно затрагивать расчёт отчёта.

class Report {
    public String generate() {
        return "Sales report data";
    }
}

class ReportSaver {
    public void saveToFile(String report) {
        System.out.println("Saving report: " + report);
    }
}

public class Main {
    public static void main(String[] args) {
        Report report = new Report();
        ReportSaver saver = new ReportSaver();

        String data = report.generate();
        saver.saveToFile(data);
    }
}

Пояснение кода:

Код не требует сложного разбора по алгоритму, здесь важна архитектурная идея. Report отвечает только за формирование содержимого отчёта. ReportSaver отвечает только за сохранение результата. Если завтра поменяется способ сохранения, например на запись в базу или отправку по сети, класс Report останется без изменений.

Ключевые моменты:

SRP = одна ответственность = одна причина для изменения.
Если класс делает слишком много, его проще ломать и сложнее тестировать.
Разделение ответственности обычно приводит к более мелким и понятным классам.
SRP не значит, что класс должен быть «совсем маленьким», важно именно разделение зон ответственности.
На собеседовании полезно привести пример из реального кода: сервис, репозиторий, логгер, валидатор.

Можешь привести пример принципа S из принципов SOLID в практике?