😎 Принцип DRY в программировании

• Что такое DRY? 🥱
Если по-русски, то “Don’t Repeat Yourself”
(Не поворяйся!)
Вкратце - это значит, что нужно стараться не допускать дублирования кода, и, выносить повторяющуюся логику по мере необходимости.
К примеру для этого во многих проектах и фреймворках есть Helpers, да и в целом сами библиотеки и фремворки не только ускоряют работу, но и решают множество других задач, в том числе DRY

• Зачем он нужен? 🤨
Дублирование кода усложняет поддержку и доработку проекта.
Если изменить логику такого блока - придется вспомнить и изменить все остальные дубли, где эта логика исопльзовалась.

• Как его применять? 🍴
Выше я уже описал пример с хелперами - можно писать свои. Это у нас - создание функций, содержащих повторяющуюся логику, не влияющую на окружение.
А еще это может быть использование циклов или других структур, например - классов и их наследования.

• Пример 💻
Функции на скринах взаимодействуют с апи, а соблюдая DRY - еще и создают удобный интерфейс апи.
На первом и втором узображении функции созданы в целях соблюдения DRY.
Но внутри самой функции на первом скрине - этот же принцип и нарушен, так как если в проекте есть другие запросы - придется дублировать логику самого запроса в новые функции.
На втором скрине абсолютно тот же запрос, но логика запроса вынесена в отдельную функцию.
А на третьем скрине - та самая логика, которая покрывает POST и GET запросы, внутри которых снова используется принцип DRY, и они служат лишь интерфейсом для запроса, который исоплняется только в функции request.

• Исключения ⛔️
Важно помнить, что это не панацея и не строгое правило.
Иногда дублирование кода может быть оправдано, если это делает код более понятным или упрощает его.
Главное не переусердствовать и четко понимать, почему сейчас нужно применить или нарушить этот принцип.

Не, ну посмотрите, какая маленькая, аккуратная и понятная функция на втором скрине)
Да post и get функции тоже приятные.
Главное не найти дублирования в request - это предел, дальше все резко ухудшится 😁