Есть ли конфликт между DRY и Single Responsibility?

Принципы DRY (Don't Repeat Yourself) и Single Responsibility Principle (SRP) — это два фундаментальных подхода к написанию чистого и поддерживаемого кода. DRY направлен на минимизацию дублирования знаний в системе, что обычно означает устранение повторяющегося кода. SRP, являясь частью SOLID, утверждает, что класс или модуль должен иметь одну и только одну причину для изменения, то есть одну ответственность.

Где возникает напряжение?

Конфликт не является прямым, но может проявиться, когда разработчик, следуя DRY, начинает агрессивно выносить любой повторяющийся фрагмент кода в общие утилиты или базовые классы. Это может привести к созданию "божественного объекта" или сервиса, который знает и делает слишком много разного, тем самым нарушая SRP. Такой компонент становится хрупким, так как изменения в одной части системы могут потребовать его модификации, затрагивая множество других, казалось бы, несвязанных мест.

Пример практического противоречия

Представьте, что у вас есть два класса: InvoiceSender (отправляет счета) и ReportGenerator (генерирует отчеты). Оба используют один и тот же сложный алгоритм форматирования даты.

// Нарушение DRY - дублирование кода
class InvoiceSender {
    formatDate(date) {
        // Сложная логика форматирования
        return `${date.getDate()}.${date.getMonth()+1}.${date.getFullYear()}`;
    }
    send() { /* ... использует formatDate ... */ }
}

class ReportGenerator {
    formatDate(date) {
        // Точная копия логики из InvoiceSender
        return `${date.getDate()}.${date.getMonth()+1}.${date.getFullYear()}`;
    }
    generate() { /* ... использует formatDate ... */ }
}

Следуя DRY, мы выносим метод formatDate в отдельный класс.

// Попытка соблюсти DRY
class DateFormatter {
    static format(date) {
        return `${date.getDate()}.${date.getMonth()+1}.${date.getFullYear()}`;
    }
    // Позже добавляем логику парсинга даты из строки для другой части приложения
    static parse(dateString) { /* ... */ }
    // Затем добавляем конвертацию временных зон...
}

Теперь DateFormatter рискует нарушить SRP, если начнет обрабатывать все, что связано со временем (форматирование, парсинг, конвертация, валидация). Его причина для изменения становится размытой.

Как найти баланс?

Решение заключается в тщательном анализе природы дублирования:

• Случайное дублирование: Если код выглядит похоже, но представляет разные концепции (например, форматирование почтового индекса и номера телефона), выносить его в общую функцию — ошибка. Это нарушит SRP.
• Сущностное дублирование: Если это одна и та же бизнес-логика или правило (например, расчет налога), то создание отдельного модуля с единственной ответственностью (например, TaxCalculator) удовлетворит и DRY, и SRP.

В примере с датой, если форматирование требуется только для отображения в UI, правильнее будет создать отдельный модуль DisplayDateFormatter с единственной ответственностью — подготовка дат для показа пользователю. Если позже понадобится парсинг дат из пользовательского ввода, это будет другая ответственность, и для нее стоит создать отдельный модуль.

Вывод: Конфликт между DRY и SRP — это миф при правильном понимании. DRY борется с дублированием знаний (одного и того же правила или алгоритма), а SRP — с дублированием причин для изменения. Грамотное проектирование заключается в том, чтобы выносить в отдельные модули именно единые области знаний, которые и будут иметь одну ответственность. Если при объединении кода ответственность модуля становится нечеткой, вероятно, вы объединяете разные знания, и это нарушает SRP, даже если соблюдается буква DRY.