Ответ
Принцип DRY (Don't Repeat Yourself) применяется для борьбы с дублированием знаний или намерений в коде. Это не только про повторение строк, но и про повторяющуюся логику, конфигурации или структуры данных.
Типичные случаи применения:
- Повторяющиеся фрагменты кода: Вынесение в отдельный метод, функцию или класс.
- Общая бизнес-логика в нескольких местах: Создание общего сервиса или компонента.
- Одинаковые условия или проверки: Использование стратегии или спецификации.
- Константы и конфигурации: Вынесение в централизованные файлы настроек или классы констант.
Пример нарушения и исправления:
// Нарушение DRY: логика форматирования даты дублируется.
string report1 = "Report generated on " + DateTime.Now.ToString("yyyy-MM-dd");
string report2 = "Data processed on " + DateTime.Now.ToString("yyyy-MM-dd");
// Следование DRY: логика изолирована в одном месте.
public static class Formatter
{
public static string FormatCurrentDate() => DateTime.Now.ToString("yyyy-MM-dd");
}
string report1 = $"Report generated on {Formatter.FormatCurrentDate()}";
string report2 = $"Data processed on {Formatter.FormatCurrentDate()}";
// Теперь при необходимости изменить формат даты, правка делается в одном месте.Важное замечание: DRY не следует применять слепо к случайно совпадающему коду. Если два фрагмента логически различны и могут изменяться по независимым причинам, их дублирование может быть предпочтительнее преждевременной абстракции.
Ответ 18+ 🔞
А, слушай, вот этот ваш DRY, принцип такой. Ну, в общем, идея проще пареной репы, но её постоянно, блядь, неправильно понимают, ядрёна вошь! Это не про то, чтобы скопипастить три строчки и орать "ой, дублирование!". Нет. Это про дублирование знаний, ёпта! То есть если у тебя одно и то же правило, одна логика или одно намерение распиздяйски размазано по десяти файлам — вот это пиздец. Менять потом придётся везде, и обязательно в одном месте забудешь, и будет тебе хиросима.
Где обычно этот конёк встаёт на дыбы:
- Одинаковые куски кода в разных методах: Ну вынеси ты их в отдельную функцию, что тебе, жалко? Не будь мудёй.
- Одна и та же бизнес-хрень торчит из пяти разных модулей: Делай общий сервис, компонент, чёрта в ступе — только не копируй!
- Одни и те же проверки или условия: Господи, ну сделай стратегию, спецификацию, хоть что-то — лишь бы не плодить одно и то же.
- Константы и настройки раскиданы как попало: Собери в кучу, в один файл! А то потом будешь искать, где ещё этот "Timeout = 100500" зарыт.
Смотри, как бывает:
// Вот это пиздопроебищно (нарушение DRY). Одна логика — формат даты — задублирована.
string report1 = "Report generated on " + DateTime.Now.ToString("yyyy-MM-dd");
string report2 = "Data processed on " + DateTime.Now.ToString("yyyy-MM-dd");
// А вот так — уже красота. Знание о том, КАК мы форматируем дату, живёт в одном месте.
public static class Formatter
{
public static string FormatCurrentDate() => DateTime.Now.ToString("yyyy-MM-dd");
}
string report1 = $"Report generated on {Formatter.FormatCurrentDate()}";
string report2 = $"Data processed on {Formatter.FormatCurrentDate()}";
// Захотел поменять формат на "dd.MM.yyyy"? Щёлк — и поменял в одном месте, а не бегай с вилкой по всему коду.Но вот тут важный момент, блядь, слушай внимательно: Не надо сходить с ума и склеивать всё, что выглядит похоже. Если два куска кода случайно совпали, но они про разные вещи и могут меняться по разным причинам — оставь их в покое! Слепить их в одну абстракцию — это заранее себе яму выкопать. Получится этакая манда с ушами, которую потом ни туда, ни сюда. Иногда дублирование лучше, чем, блять, неправильная абстракция. Доверия к таким преждевременным выносам — ноль ебать.
