🟢 Junior Level

Когда класс имеет несколько причин для изменения (нарушение SRP), он становится хрупким и сложным. Любое маленькое изменение может сломать совершенно unrelated функциональность.

Простая аналогия: Представьте швейцарский нож с 50 инструментами. Если нужно поменять лезвие — придётся разобрать весь нож. А если сломаешь отвертку — перестанет работать и штопор.

Пример нарушения:

// Плохо: 4 разные причины для изменения
public class User {
    private String name;              // Данные
    
    public void validate() { }        // Валидация (меняют юристы)
    public void save() { }            // Сохранение (меняют DBA)
    public String toJson() { }        // Формат (меняют фронтенд)
}

Что произойдёт:

• Изменение валидации → может сломать сохранение, потому что оба метода используют общие поля класса
• Изменение формата JSON → нужно перетестировать всё, так как код находится в одном файле
• Разные команды конфликтуют за один файл при merge

Как исправить:

// Хорошо: каждая ответственность в своём классе
public class User { private String name; }              // Только данные
public class UserValidator { void validate(User u) { } } // Только валидация
public class UserRepository { void save(User u) { } }    // Только БД
public class UserMapper { String toJson(User u) { } }    // Только формат

---

🟡 Middle Level

Как это работает

Когда класс имеет несколько причин для изменения, он становится “Жестким” (Rigid) и “Хрупким” (Fragile). Каждая ответственность — это “ось вращения изменений”. Если их несколько — класс разрушается при нагрузке.

Последствия для проекта

Проблема	Описание	Влияние
Cognitive Load	Класс с 5 ответственностями = сотни комбинаций	Разработчики боятся менять код
Fragility	Изменение в одном месте ломает другое	Каскадные баги
Merge Conflicts	Разные команды меняют один файл	В крупных проектах — значительная часть времени уходит на разрешение конфликтов

Практическое применение

Метрика Cognitive Complexity (SonarQube):

• Метод > 15 → сложно поддерживать
• Класс > 200 строк → трудно удержать всю логику в голове, растёт риск багов

Code Churn анализ (метрика частоты изменений файла):

• Если файл меняется в большинстве коммитов → слишком много причин для изменения

Типичные ошибки

Ошибка	Решение
God Object (класс с десятками полей и методами на все случаи жизни)	Разделить по ответственностям
Butterfly Effect (1 изменение → 10 правок в других файлах — эффект бабочки)	Выделить отдельные сервисы
Daily merge conflicts (ежедневные конфликты при слиянии веток)	Package-by-Feature (группировка по фичам, а не по слоям)

Когда НЕ стоит строго следовать SRP

• Прототипы/MVP (быстрая проверка)
• Скрипты миграции (одноразовый код)
• Когда стоимость изменений минимальна

---

🔴 Senior Level

Internal Implementation: Механика хрупкости

Shared State Problem:

class GodObject {
    private Date lastProcessed;  // Используется для логирования И бизнес-логики
    // Изменение формата даты в логах ломает расчеты
}

Memory Layout Issues:

• False Sharing: Поля разных ответственностей попадают в одну cache line (64 bytes)
• Impact: Ядра CPU инвалидируют кэш друг друга → slowdown 10-100x

Архитектурные Trade-offs

Строгий SRP:

• ✅ Плюсы: Минимум side effects, параллельная разработка, easy testing
• ❌ Минусы: Class explosion, navigation complexity, communication overhead

Умеренный SRP:

• ✅ Плюсы: Баланс между чистотой и практичностью
• ❌ Минусы: Требует зрелого суждения, риск постепенной деградации архитектуры

Edge Cases

1. Lock Contention: Singleton God Object → разные потоки борются за один монитор
   • Решение: Разделение на separate beans с independent locks
2. Metaspace Impact: Huge classes → больше bytecode → больше metaspace
   • Impact: +2-5MB на класс 5000+ строк
3. Transaction Boundaries: Один класс координирует транзакцию через несколько доменов
   • Решение: Orchestrator pattern (класс-координатор, который вызывает отдельные сервисы в правильном порядке, но не содержит их бизнес-логику), @Transactional на координаторе

Производительность

Метрика	God Object	SRP Compliant
Cognitive Complexity	50-200+	<15
L1 Cache Hit Rate	40-60%	85-95%
Lock Contention	High (single monitor)	Low (independent locks)
Test Execution	Slow (many mocks)	Fast (isolated)

False Sharing Impact:

Поле A (логирование) и Поле B (бизнес-логика) в одной cache line
→ Thread 1 пишет A → invalidates Thread 2's cache for B
→ 10-100x slowdown при высокой конкуренции

Thread Safety

• Single monitor bottleneck: Все потоки ждут один God Object
• Independent services: Разные lock’и → parallel execution
• Contention rate: God Object → 60-80% wait time, SRP → <10%

Production Experience

Рефакторинг BillingEngine (15,000 строк):

Проблема:

• 8 ответственностей: расчёт, валидация, БД, email, PDF, аудит, кэш, логирование
• Cognitive Complexity: 340 (норма < 15 — показатель запутанности кода от SonarQube)
• Merge conflicts: ежедневно, 2-3 часа на разрешение
• Bug rate: 40% деплоей с багами

Решение (6 спринтов):

1. Feature Analysis: сгруппировали методы по доменам
2. Извлекли: TaxCalculator, InvoiceGenerator, PaymentProcessor
3. Создали BillingOrchestrator для координации
4. Event-driven: BillingCompletedEvent для аудита/emails

Результат:

• Cognitive Complexity: 8-12 на класс
• Merge conflicts: <1 в месяц
• Bug rate: 8% деплоей
• Deployment time: 30 мин → 5 мин

Monitoring

ArchUnit:

@ArchTest
static void no_god_objects = classes()
    .should().haveLessThanNMethods(30)
    .andShould().haveLessThanNFields(15)
    .andShould().haveLessThanNDependencies(7);

SonarQube:

• Cognitive Complexity > 15 → Code Smell
• Class size > 300 lines → Refactoring candidate

Git Analysis:

# File change frequency
git log --oneline -- User.java | wc -l
# If >90% of commits touch this file → SRP violation

Best Practices for Highload

• Max 300 lines per class
• Max 15 fields per class
• Max 7 dependencies
• Package-by-Feature для модульности
• ArchUnit CI checks
• Code churn monitoring в Git

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Класс с несколькими причинами для изменения = “Жесткий” (Rigid) и “Хрупкий” (Fragile)
• Cognitive Load: сотни комбинаций → разработчики боятся менять код
• Butterfly Effect: 1 изменение → 10 правок в других файлах
• False Sharing: поля разных ответственностей в одной cache line → slowdown 10-100x
• God Object → single monitor bottleneck → 60-80% wait time в многопоточной среде
• Orchestrator pattern решает проблему: координация без бизнес-логики
• Метрики: Cognitive Complexity > 15, Class size > 300 строк, Dependencies > 7

Частые уточняющие вопросы:

• Что такое Shared State Problem? — Поле используется для разных целей (логирование И бизнес-логика), изменение формата ломает расчёты
• Как God Object влияет на Thread Safety? — Один монитор на весь объект → все потоки ждут, contention rate 60-80%
• Что такое Code Churn? — Метрика частоты изменений файла; >90% коммитов трогают файл → SRP violation
• Какой результат рефакторинга? — Cognitive Complexity 8-12, bug rate 8%, deployment time 5 мин вместо 30

Красные флаги (НЕ говорить):

• “Небольшое нарушение SRP — это нормально” (каскадные баги и merge-конфликты накапливаются)
• “God Object можно исправить за один спринт” (реальные кейсы: 6 спринтов для 15,000 строк)
• “SRP только для больших классов” (класс из 30 строк может делать 3 вещи)

Связанные темы:

• [[1. Что такое принцип Single Responsibility и как его применять]]
• [[13. Как принцип Single Responsibility связан с cohesion]]
• [[18. Как рефакторить God Object (божественный объект)]]
• [[21. Как определить, что класс имеет одну ответственность]]