Что Такое Принцип Dry В Программировании С Примерами

Например, у объекта «сетевое подключение» могут быть интерфейсы «подключиться», «отключиться», «проверить связь» и «передать данные». Принцип разделения означает, что если мы поменяем внутри что-то в одном интерфейсе, это не должно сломать работу остальных интерфейсов. У разработчиков есть свои термины, которыми они описывают разные принципы разработки — например DRY, SOLID и YAGNI. Рассказываем, что они означают и что имеют в виду программисты, когда говорят такое.

Если предположить, что это единственное место, где эта логика определена, то код в данном репозитории соответствует принципу DRY. Однако со временем, как и многое другое в программной инженерии, его смысл и обоснование, на мой взгляд, были утрачены. Вместо того чтобы применять его по мере необходимости, он используется при малейшем подозрении на дублирование, что, по-моему, чревато ухудшением кода в долгосрочной перспективе. “Не повторяйся” (Don’t Repeat Yourself, DRY)  —  один из самых распространенных принципов программирования, регулярно упоминаемый при рассмотрении запросов на включение изменений. Первоначально обоснование соблюдения принципа DRY было вполне разумным.

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

Таким образом, мы выяснили, что слепое использование DRY может навредить проекту. Именно поэтому рефакторинг или объединение кода должны опираться на глубокое понимание причин и природы дублирования – без них оптимизировать программное обеспечение невозможно. Стоит отметить, что мы обсуждали DRY только в контексте одного репозитория.

Применение Принципа Dry

И раз уж мы заговорили о каскадной модели, то нельзя не вспомнить о принципе Big design up entrance («Масштабное проектирование прежде всего»), который идеально для неё подходит. Он утверждает, что большую часть времени, отведённого на проектирование приложения, вы тратите далеко не на написание кода. Возможно, при работе с MyModule кому-то и захочется реализовать методы shut и open, но если не требуется обеспечить совместимость с IE8, то последний из трёх перечисленных в коде методов точно не понадобится. Другими словами, LSP гарантирует правильное использование наследования в вашем коде.

Однако использование принципа DRY не всегда работает так гладко, как в предыдущем примере. Проблемы зачастую возникают у стартапов, в которых разработчики на ранних этапах развития проекта поспешно выносят в общий модуль блоки с одинаковым кодом или структуры с одинаковым набором полей. По мере развития проекта объединенные модули часто начинают развиваться в разных направлениях, а значит, разнонаправленно должен развиваться и общий модуль.

Принцип Программирования Dry — Don’t Repeat Yourself / Не Повторяйте Себя

Смотрите, как сразу все стало аккуратно, файл выглядит более простым и занимает визуально меньше места. Теперь можно вызывать нашу новую функцию generateInt() везде, где захочется (в пределах файла), и для этого не требуется повторять одни и те же три строчки кода. Удалив дублирование, мы без необходимости связали большое количество классов.

Стоит не внести изменение в одном месте (что вполне вероятно), и в разных частях приложения будет применяться разная логика. Следовать принципу «don’t repeat yourself» в рамках больших проектов не так просто, как это может показаться на первый взгляд. От разработчиков требуется тщательное планирование архитектуры, а от архитектора или тимлида требуется наличие видения системы в целом и чёткая постановка задач разработчикам. Смысл в том, чтобы зависимости, например от внешней базы данных, не встраивались жёстко в тело модуля, а были одним из аргументов, от которых зависит выполнение этого модуля. Если нам нужно будет поменять базу данных, с которой работает модуль, достаточно будет сделать это при вызове, а не править исходную функцию.

Рассмотрим фрагмент кода с двумя классами, в котором есть дублирование. Это пример из реального проекта (я лишь упростил код, чтобы ограничить количество представленных данных). Я видел множество комментариев к запросам на включение изменений, где авторы неправильно полагали, что код должен быть обновлен, чтобы соответствовать принципу DRY, в то время как был смысл в дублировании кода. Если отойти от программирования, можно вспомнить и другие аббревиатуры, которые часто используются в нашей отрасли. Не путайте его с уже упоминавшимся Single duty precept (принципом единственной ответственности). Суть в том, что при проектировании многофункциональной системы — а так обычно и бывает — можно группировать функции в модули в зависимости от задач, которые каждая из них выполняет.

Он используется на этапе до MVP и предназначен только для того, чтобы подтвердить или опровергнуть необходимость дополнительной функциональности. Соблюдая его, отделяйте методы друг от друга — пусть пользователи сами решают, какие из них применять и для каких задач. Функции, которые используют указатели или ссылки на базовые классы, должны иметь возможность использовать подтипы базового типа, ничего не зная об их существовании.

Коротко Об Использовании Dry

Создаем как отдельные инструменты для бизнеса, так и полноценные цифровые системы по индивидуальным требованиям. KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. SOLID — это целый набор правил, а название образовалось по первым буквам каждого из них. Такой подход часто используется в крупных проектах и в командной работе над кодом. Предлагаю поразмышлять над тем, почему дублирование не является источником всех бед и почему совершенно нормально иногда повторяться. В отличие от MVP, который требует серьёзного планирования и больших затрат на разработку, Proof of concept принципы разработки по (доказательство концепции) обычно представляет собой его урезанную версию.

• Однако если бы в другом месте была вторая часть кода, использующая ту же логику, это считалось бы нарушением принципа DRY, так как бизнес-правило было бы продублировано в двух местах.
• В отличие от MVP, который требует серьёзного планирования и больших затрат на разработку, Proof of idea (доказательство концепции) обычно представляет собой его урезанную версию.
• Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё дважды)[5] или «We take pleasure in typing» (рус. Нам нравится печатать).
• Он говорит о том, что каждая ваша функция должна выполнять только одну задачу.
• Если информация хранится только в одном месте, то изменения и обновления могут быть произведены в одном месте, и они автоматически будут отражены во всех остальных местах, где эта информация используется.

Каждая часть информации должна иметь единое, однозначное, авторитетное представление в системе. Включать PoC в реальный продукт, в принципе, можно, но имейте в виду, что для доказательства одной концепции, бывает, приходится создавать несколько PoC. Корпеть над ними всеми, чтобы получить в итоге один актуальный продукт, — так себе идея. Так что его намеренно говнокодят, чтобы потом было не жалко выбрасывать. Separation оf issues (принцип разделения ответственности) — один из моих любимых.

Типа Архитектуры Программного Обеспечения

YAGNI призывает избегать внедрения функциональности, которая в настоящий момент не требуется, но может понадобиться в будущем. Принцип YAGNI призывает к созданию только той функциональности, которая необходима для решения текущих задач и требований, и отложению добавления неиспользуемой функциональности на будущее. Эта техника помогает участникам проекта выделить предметные области и достаточно точно определить, существует ли дублирование знаний между разными модулями, и решить, выделять ли их в общее место. Доменно-ориентированное проектирование (DDD) – это подход к разработке программного обеспечения, при котором упор делается на создание софта, который отражает реальные бизнес-процессы и проблемы. Объединив два разных случая вычисления площади в одну универсальную функцию, можно упростить процесс поддержания кода.

Это Классика, Это Знать Надо: Dry, Kiss, Stable, Yagni И Другие Полезные Сокращения

Поэтому важно различать между схожими блоками кода, которые описывают различные аспекты знаний, и действительно одинаковыми блоками кода, которые дублируют одно и то же знание. При применении принципа DRY важно сосредотачиваться на устранении дублирования смысловой информации, а не просто кода. В системе должен существовать только один основной источник данных или информации, который является авторитетным и актуальным. Если информация хранится только в одном месте, то изменения и обновления могут быть произведены в одном месте, и они автоматически будут отражены во всех остальных местах, где эта информация используется.

Принцип Dry

Однако если бы в другом месте была вторая часть кода, использующая ту же логику, это считалось бы нарушением принципа DRY, так как бизнес-правило было бы продублировано в двух местах. Теперь можно даже переключать зависимости — например, использовать другой модуль для подключения к базе данных — на коде это не отразится, он всё так же будет отрабатывать необходимую логику. Здесь мы видим, что подключение к базе данных объявлено и выполняется внутри одного модуля, а функцию saveUser вы экспортируете. Если теперь попытаться протестировать код, эта функция автоматически постарается выполнить свою первоначальную задачу — подключиться к базе данных и сохранить данные пользователя в ней. Он подразумевает, что каждый кусок информации (код, данные и т.д.) должен иметь только один, четко определенный “источник правды” в системе. Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза).

Single Duty Principle, Принцип Единственной Ответственности

SoC также может применяться при создании API, архитектур библиотек и тому подобного. Его суть в том, чтобы группировать функции по своему усмотрению и с пользой для тех, кто будет их применять. Конечно, как и у многих других описанных здесь принципов, у BDUF есть свои противники. Особенно склонны нападать на него сторонники гибких методологий — они полагают, что в мире победившего Agile он просто бесполезен.

Программисты придумали всё это чтобы работать по единым стандартам в команде или компании. Например, если команда придерживается DRY-подхода, то на код-ревью тимлид будет ругаться на одинаковые по функционалу модули. А если в компании работают по принципам SOLID, то там наоборот, у модулей может быть похожий смысл, но каждый модуль будет решать свою отдельную задачу. Например, если разработчик не знает кодовую базу, он может  неосознанно повторить уже существующую в проекте модель данных. Дублирование также возникает как результат других процессов, например, когда разные команды независимо друг от друга создают похожие решения для разных частей одного проекта. В методе add_location_context нет бизнес-логики  —  это простой код, который необходим в совершенно несвязанных частях кодовой базы.

Смысл принципа DRY — не писать новый код, если уже есть старый, который делает то, что нам нужно. Если его возможностей немного не хватает, то программист думает, как их туда добавить, не сломав исходную функцию. Принцип DRY — это полезный инструмент разработки, который часто используют неправильно, что приводит к проблемам в процессе разработки. Поэтому для оптимизации кодовой базы крайне важно понимать причины дублирования и его разновидности. А сделать обоснованные решения о структуре и организации кода для его долгосрочной устойчивости и масштабируемости помогут практики моделирования, такие как DDD и Event Storming. Следование принципу DRY приводит к модульной архитектуре проекта, что положительно сказывается на возможности его обслуживать долгие годы.

В обоих блоках кода выполняется похожая операция — умножение длин сторон. В случае квадрата — это умножение длины стороны саму на себя, а для прямоугольника — умножение длины на ширину. Возможно, https://deveducation.com/ в следующий раз, собираясь удалить дублирование, вы подумаете, имеет ли смысл делать это. Итак, мы выяснили, для чего предназначен принцип DRY и как правильно его использовать.