---
name: solid-dry-code
description: >-
  Enforces Single Responsibility Principle (SRP) and DRY: one class/function
  one job, extract shared behavior into reusable functions or classes. Use when
  writing, generating, or reviewing code in any language; when refactoring or
  when the user mentions duplication, SRP, SOLID, or clean code.
---

# SRP и DRY при написании кода

При генерации или правке кода соблюдай принцип единственной ответственности (SRP) и избегай дублирования (DRY). Применяется к любому языку.

## Single Responsibility (SRP)

- **Один класс / один модуль / одна функция — одна зона ответственности.** У каждой сущности одна причина для изменения.
- Если описание требует «и» (валидация **и** сохранение **и** отправка письма) — разбить на отдельные функции или классы.
- Большие функции (>20–30 строк) или классы с разными «блоками» логики — кандидаты на разбиение: выделить подзадачи в отдельные функции/классы с говорящими именами.

**Проверка:** можно ли описать ответственность одной короткой фразой без «и»? Если нет — разделить.

## DRY (Don't Repeat Yourself)

- **Одинаковая логика в двух и более местах — вынести в общую функцию или класс.** Копирование кода с минимальными отличиями (например, только другой тип или параметр) — нарушение DRY.
- Повторяющиеся последовательности вызовов — оформить как функцию с параметрами или фасад.
- Общая структура данных и поведение у нескольких типов — рассмотреть базовый класс, композицию или утилитарные функции вместо копирования.

**Проверка:** при изменении правила/формата/алгоритма придётся править несколько мест? Если да — вынести в одно место и переиспользовать.

## Практические правила

1. **Перед написанием нового кода:** проверить, нет ли в проекте уже готовой функции/класса с той же ответственностью или тем же поведением.
2. **При появлении похожего кода во втором месте:** не копировать; выделить общую часть в функцию/класс и вызывать из обоих мест.
3. **Именование:** имена функций и классов должны отражать одну задачу (например, `validate_email`, `save_user`, `send_notification`, а не `process_user` с валидацией, сохранением и отправкой внутри).
4. **Аргументы и композиция:** общее поведение передавать через параметры, зависимости или мелкие переиспользуемые функции, а не дублировать ветки кода.

## Антипаттерны (избегать)

- «God»-функция или класс, делающий парсинг + валидацию + сохранение + логирование + ответ клиенту.
- Два и более фрагмента кода с одинаковой логикой, отличающиеся только строкой/числом/типом — без выноса в общую функцию.
- Копирование целых блоков с заменой одного идентификатора (признак того, что нужна параметризованная функция или общий модуль).

## Итог

Перед сохранением кода задать себе: у каждой единицы одна ли ответственность? повторяется ли логика в других местах? Если да на дублирование — вынести общее; если нет на единственность ответственности — разбить на более мелкие сущности.
