Dry don t repeat yourself

Это классика, это знать надо: DRY, KISS, SOLID, YAGNI и другие полезные сокращения

Эти сокращения каждый программист должен знать так же хорошо, как количество и имена истребителей у адмирала Ямомото.

Иллюстрация: Artur Kovalev / Wikimedia Commons / Colowgee для Skillbox Media

Фернандо Дольо
(Fernando Doglio)

Один из топовых авторов на Medium. Пишет о технологиях, образе жизни, личном опыте и многом другом.

За 17 лет работы в индустрии я каких только сокращений не повидал — и серьёзных, и забавных. Да и, если честно, всем разработчикам нравятся аббревиатуры. Одни просто облегчают речь — например, MVP или PoC (ясно же, что, создавая их, никто особо не усердствовал). Другие ещё и звучат забавно: например, SOLID, DRY и KISS.

Вообще, аббревиатур в сленге разработчиков так много, что я подготовил небольшой обзор наиболее (и парочки — менее) распространённых из них — вдруг вы подзабыли, что они означают.

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

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

Другими словами, don’t repeat yourself, понимаете?

Этот принцип полезен всегда, вне зависимости от платформы или языка. Допустим, вам надо автоматизировать некое поведение. Чтобы не прописывать несколько раз одну и ту же логику и не раздувать код без нужды, попробуйте обобщить её и вынести в отдельный элемент.

Лайфхак: принцип DRY не нужно ограничивать одним репозиторием. Чтобы упростить доступ к модулям или компонентам при работе с разными репозиториями, используйте Bit (вот его страница на GitHub). Он поддерживает Node.js, TypeScript, React, Vue.js, Angular и другие фреймворки.

Эта аббревиатура (англ. kiss — поцелуй, целовать) мне самому всегда нравилась — как по форме, так и по значению: Keep it simple, stupid («Сделай это проще, тупица») или, если кому-то не нравится называться тупицей, есть вариант Keep it stupid simple («Пусть всё будет простым до безобразия»), который ещё лучше передаёт смысл аббревиатуры.

Решая какую-нибудь проблему, можно так увлечься, что сам не заметишь, как уже занялся оверинжинирингом или, как я люблю говорить, вовсю палишь из пушки по воробьям. Задача в итоге, конечно, будет решена — но её можно было бы выполнить куда проще и изящнее.

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

Проверяйте, достаточно ли понятны ваши логические цепочки. Хватит ли знаний вашим коллегам, чтобы в них разобраться? Простой код и простой дизайн уменьшают риск ошибок, да и читать такой код проще. В общем, не забывайте про KISS!

SOLID

Это ещё одно общее правило программирования. Расшифровывается оно так:

Получается, что это пять разных принципов в одном (англ. solid — твёрдый, плотный, прочный). Рассмотрим каждый по отдельности.

1. Single responsibility principle, принцип единственной ответственности

Он говорит о том, что каждая ваша функция должна выполнять только одну задачу.

Если вы знакомы с *NIX-системами, такими как дистрибутивы Linux, macOS и прочие, то наверняка имели дело с их терминалом и командами, например ls или cd. Они строго следуют принципу SRP — выполняют только один тип задачи (скажем, меняют директорию или выводят список её содержимого). Вы не найдёте такой утилиты, которая позволяла бы выполнить сразу несколько задач (в нашем примере — изменить директорию и вывести список её содержимого). Это даже называется UNIX-way.

Чтобы иметь только одну ответственность, функции должны быть простыми. Если же нужно более сложное поведение, придётся объединять вводы и выводы нескольких функций и делать композицию.

И хоть я и говорю сейчас о функциях, принцип SRP применим практически ко всему. Взять, например, архитектуру какой-нибудь платформы. Её гораздо проще обслуживать и развивать, если вместо мегамодуля, ответственного вообще за всё, у вас будет несколько микросервисов, каждый из которых отвечает за свою маленькую задачу. Но — ещё раз — то же касается и функций: более простые и понятные функции легче поддерживать, читать, понимать и даже просто писать.

Например, если вам нужна функция getUserAndRelatedBooks, в которой прописана логика двух задач, подумайте о том, чтобы разбить её на две функции: getUser и getUsersBooks, где вторая будет получать на вход результат выполнения первой. Так вы сможете изящно реализовать getUserAndRelatedBooks, просто указав getUsersBooks (getUser), то есть объединив их в композицию.

2. Open-closed principle, принцип открытости/закрытости

Он говорит о том, что ваши модули или библиотеки (в зависимости от того, как экспортируется код) должны быть открыты для расширения (например, расширения поведения), но закрыты для модификации (ибо ни у кого нет желания возиться с чужим модулем).

Если вы заметили, что для добавления в ваш код нового поведения или расширения уже существующего его приходится править, — поздравляю, вы успешно пренебрегли принципом открытости-закрытости! 🙂

Вот наглядный пример — приведённый код нарушает этот принцип. Потому что, если понадобится добавить ещё один город, придётся открывать сам файл и вносить изменения в массив knownCities.

А вот как можно решить эту проблему и соблюсти принцип открытости/закрытости.

Как видим, с помощью метода addValidCity можно расширить поведение кода под свои задачи, без необходимости править файл.

3. Liskov substitution principle, принцип подстановки Лисков

Этот принцип, также известный как LSP, максимально приближает нас собственно к теории программирования. Сильно углубляться в неё я не буду — просто опишу суть принципа подстановки.

Функции, которые используют указатели или ссылки на базовые классы, должны иметь возможность использовать подтипы базового типа, ничего не зная об их существовании.

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

Рассмотрим это на примере. В геометрии квадрат — это разновидность прямоугольника. По сути, это прямоугольник с одинаковыми шириной и длиной. Если попытаться смоделировать это с помощью кода, можно получить примерно следующее:

В абстракции тут нет смысла: методы setWidth и setHeight ничего не меняют, квадрата из прямоугольника не получится — а это не то, что нам нужно. Итак, приведённый выше код нарушает принцип подстановки Лисков.

Другими словами, LSP гарантирует правильное использование наследования в вашем коде. Так что, как бы странно он для вас ни звучал, помнить о нём при создании классов всё-таки стоит.

4. Interface segregation principle, принцип разделения интерфейса

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

Рассмотрим этот код. Возможно, при работе с MyModule кому-то и захочется реализовать методы close и open, но если не требуется обеспечить совместимость с IE8, то последний из трёх перечисленных в коде методов точно не понадобится.

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

5. Dependency inversion principle, принцип инверсии зависимостей

Концепцию SOLID замыкает принцип инверсии, или внедрения, зависимостей.

По классике он звучит так:

Это очень полезный инструмент для многих сценариев, например для юнит-тестирования. Если вы тестируете код, который зависит от сторонней библиотеки, вы можете внедрить мок этой библиотеки для контроля поведения кода. Давайте покажу на примере:

Здесь мы видим, что подключение к базе данных объявлено и выполняется внутри одного модуля, а функцию saveUser вы экспортируете. Если теперь попытаться протестировать код, эта функция автоматически постарается выполнить свою первоначальную задачу — подключиться к базе данных и сохранить данные пользователя в ней.

Однако если разрешить внедрение зависимостей и принять соединение с базой данных (которое и является зависимостью) в качестве второго параметра, то можно внедрять мок дальше:

Теперь можно даже переключать зависимости — например, использовать другой модуль для подключения к базе данных — на коде это не отразится, он всё так же будет отрабатывать необходимую логику.

Внедрение зависимостей — замечательный инструмент. Он позволяет создавать расширяемый дизайн и очень нужен тем, кому при разработке важна расширяемость. Учитывайте это в своей работе.

YAGNI

Принцип, иначе известный как You ain’t gonna need it («Вам это не понадобится»), пришёл из экстремального программирования. Согласно ему создавать какую-то функциональность следует только тогда, когда она действительно нужна.

Дело в том, что в рамках Agile-методологий нужно фокусироваться только на текущей итерации проекта. Работать на опережение, добавляя в проект больше функциональности, чем требуется в данный момент, — не очень хорошая идея, учитывая, как быстро могут меняться планы.

Что я имею в виду, говоря про смену планов? Итерации в Agile довольно короткие — то есть вы будете получать какой-то фидбэк уже на ранних этапах разработки, и потенциально он может изменить направление всей работы над проектом. Так зачем вам тратить время на функцию, которая в итоге окажется совершенно ненужной?

Однако замечу напоследок, что если вы используете методы каскадной разработки, где вся работа планируется заранее и все стараются чётко придерживаться плана, принцип YAGNI неприменим.

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

Сама каскадная модель подразумевает, что нужно продумать заранее абсолютно всё — рассчитывая, что благодаря этому не придётся потом тратить время на поиск и устранение недостатков.

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

Separation оf concerns (принцип разделения ответственности) — один из моих любимых. Я использую его при проектировании платформ или при создании внутренней архитектуры проекта.

Не путайте его с уже упоминавшимся Single responsibility principle (принципом единственной ответственности). SoC помогает объединять функции или модули в отдельные сервисы. Суть в том, что при проектировании многофункциональной системы — а так обычно и бывает — можно группировать функции в модули в зависимости от задач, которые каждая из них выполняет.

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

Это, конечно, очень грубый пример, но суть такой архитектуры в том, что вы делите ответственность по модулям. В результате:

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

Если отойти от программирования, можно вспомнить и другие аббревиатуры, которые часто используются в нашей отрасли. MVP означает Minimum viable product (минимально жизнеспособный продукт) и предполагает создание минимально необходимой функциональности, которая помогает понять, как продукт работает в реальных условиях и нравится ли он пользователям.

Этим приёмом пользуются сплошь и рядом — чтобы выяснить, стоит ли вообще тратить время на продукт и доводить его до ума. Благодаря MVP целевая аудитория уже может опробовать продукт и дать обратную связь.

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

По сути, PoC — своего рода расходный материал, временный код. Его пишут не для реализации, а для демонстрации проекта. Включать PoC в реальный продукт, в принципе, можно, но имейте в виду, что для доказательства одной концепции, бывает, приходится создавать несколько PoC. Корпеть над ними всеми, чтобы получить в итоге один актуальный продукт, — так себе идея. Так что его намеренно говнокодят, чтобы потом было не жалко выбрасывать.

Лично мне очень нравится концепция PoC — но именно как расходного материала. Это как Железный Человек и его броня Mark I: она показала, на что он способен, даже если имеет под рукой только дуговой реактор; а Mark II была уже на несколько порядков лучше.

Заключение

Все аббревиатуры, упомянутые в этой статье, вы наверняка встречали в инструкциях и мануалах или слышали от коллег. Теперь вы знаете, что они означают и в каком контексте их употреблять.

10 заповедей разработки и тестирования

Miroslav Kungurov

1. Соблюдайте принципы YAGNI и KISS 👄

Принцип YAGNI («You aren’t gonna need it»; с англ. – «Вам это не понадобится»): не пишите код, который, как вам кажется, может пригодиться в будущем, но сейчас в нём потребности нет. Вскоре он станет неактуальным и его придётся переписать под конкретную задачу.

YAGNI минимизирует объе\ём ненужной работы и тесно связан с принципом KISS («Keep it simple, stupid»; с англ. – «Не усложняй»): избегать добавления функций и повышения сложности кода до тех пор, пока это действительно не понадобится.

2. Сначала проектируйте API для простых запросов

Что касается API, сначала проектируйте интерфейс для простых запросов. По мере необходимости добавляйте дополнительные методы для более сложных вариантов использования.

Напишите руководство, которое поможет разработчику быстро приступить к работе. При изменении API позаботьтесь об обратной совместимости.

3. Меньше кода 🔪

Будьте лаконичны и удаляйте ненужные участки кода, делая программы настолько простыми, насколько это возможно.

Меньше ненужного кода – меньше проблем

4. Следуйте стандарту, а не объясняйте всё комментариями 💬

Следование стандарту программирования упрощает обнаружение проблем, поддержку программного обеспечения, снижает риски сбоя и уязвимость к атакам.

Не злоупотребляйте комментариями. При активной разработке комментарии становятся неактуальны, поэтому изначально пишите читабельный код по стандарту вашего языка программирования, чтобы обходиться без них. Комментарии должны отвечать на вопрос «Почему», а не «Что».

Сначала пишите правильный, соответствующий стандартам код, потом оптимизируйте скорость выполнения.

5. Принцип DRY 🏜️

DRY («Don’t Repeat Yourself»; с англ. – «Не повторяйся») – принцип разработки программного обеспечения, нацеленный на уменьшение сложности кода и снижения повторения информации. Сторонники принципа DRY стремятся обеспечить существование только одного способа выполнения кода, объединяя экземпляры повторящегося кода в единый блок, что окупается в долгосрочной перспективе, т. к. ускоряет время разработки.

Ешё раз повторим: не повторяйтесь! 😋

DRY важнее в тестируемом коде, чем в тестах, потому что последние выполняются и читаются отдельно, а не как часть большой системы.

6. Пользуйтесь готовыми решениями 🚲

Используйте встроенные структуры и типы данных, пишите свои только по необходимости. Ведь за готовыми решениями стоят годы отладки и оптимизации.

7. Сначала пишите тесты 📝

Юнит-тест проверяет поведение кода, а не его реализацию. Относитесь к своим тестовым объектам как к «чёрным ящикам», тестируемым через публичный API.

Как выглядит тестирование в процессе разработки

Предварительное написание тестов побуждает использовать небольшие единицы кода, что в большинстве случаев приводит к написанию более чистого кода.

Тесты должны быть написаны так, чтобы их можно было использовать, как документацию.

8. О скорости юнит-тестов

Небольшие юнит-тесты дают в случае неудачи более ценную информацию – они явным образом указывают что именно не так. Как правило, тест, на который уходит больше 0.1 с, юнит-тестом не является.

9. Рефакторинг

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

Как не должен выглядеть рефакторинг

10. Проверяйте тесты

Сделайте преднамеренную ошибку и убедитесь, что тест работает. В противном случае вы не знаете, что действительно тестируете. Нерабочие тесты уменьшают пользу вашего набора тестов, до такой степени, что, в конце концов, все игнорируют их результаты. Исправляйте или удаляйте такие тесты.

Юнит-тесты

Итак, мы вспомнили о таких принципах программирования как YAGNI, KISS и DRY. Также узнали, какой юнит-тест считается медленным и как нужно проводить рефакторинг.

Вот ещё пара материалов по теме публикации:

Don’t Repeat Yourself: Get More Done with the DRY Principle

We’ve all nodded along when someone says we need to work smarter, not harder. But what does that mean, in practical terms?

Computer programmers have an answer with a concept they use to write more efficient code: Don’t Repeat Yourself (DRY). You don’t have to be a coder to use the same principle in your day job, so let’s take a look at how to apply it to your daily tasks.

What Is DRY?

The term «don’t repeat yourself» was coined in 1999 by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They defined it as «Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.»

In software engineering, DRY is the principle of reducing repetition in the code, referring back to a single source—or «snippet»—of reusable code whenever you need it.

In addition to saving effort upfront, it also means less room for human error: If you write the same thing 24 times, you’re bound to mess up at least once. Plus, if you decide, for example, that your app needs to throw a bone instead of a ball, you just need to change the code once, rather than 24 times.

Coders have a sense of humor, so they’ve also come up with an antonym for DRY: WET, which can mean either We Enjoy Typing or Wasting Everyone’s Time, depending on who you ask.

That’s an example from coding, but we all instinctively avoid repetition where there’s an obvious solution. We let websites store cookies on our computer to remember our preferences. We create playlists of our favorite songs, rather than choosing from scratch each time. And we load contacts into our phone instead of typing in numbers for every text.

But how can we avoid repetition and save time when it comes to our work? It all starts with a figuring out where you’re repeating yourself.

Discover Where You Repeat Yourself

If you’ve ever tried a productivity system, a lot of this will sound familiar. Systems like Getting Things Done (GTD) and Zen to Done follow a similar process. The difference here is that we’re approaching the process with a laser focus on unnecessary duplication.

The first step is logging your daily activities—you’ll need to do this for at least a week, but ideally a month. As you track your time, you’ll be logging routine tasks, but you don’t want to miss the tasks that come around less often or not as regularly.

Add tasks that are likely but unplanned, such as dealing with a customer complaint.

Don’t forget about annual tasks (or monthly, if you’re only tracking for a week): things like reports, audits, inspections, invoicing, maintenance, and more.

Ask others for their routine tasks. That’ll help you fill in the gaps.

If it’s worth doing, it’s worth logging. To make the task-logging process easier, check out our selection of the best to-do list apps and the best time-tracking apps. If you’re not interested in adopting a new app for the process, you can always use a spreadsheet.

At this point, you have a high-altitude view of your tasks. Now it’s time to work out which tasks are prime candidates for DRY. This can be completed in whatever app you’ve used to track your tasks. You can create tags or labels for each category in your to-do list or time-tracking app, add the categories as additional columns in a spreadsheet, or simply jot them down with pen and paper.

We suggest you focus on four key areas, making a note of any tasks that fall in one or more of the following categories.

Pain points. Looking through your list, there’s probably a handful of tasks that turn your stomach like a pretzel. Maybe you dread writing the monthly report or sending reminders to late-paying clients. Go with your gut on this one. If it produces a physical reaction of panic and revulsion, or you find yourself procrastinating whenever this task comes up, tag it.

Bottlenecks. Which tasks hold up the rest of your day? Maybe you have to email all the department heads and wait for their responses before you can start work on a report. Or maybe you need to import new customer data before running the analytics you’re interested in.

Time-consuming tasks. This is where the results of your time-tracking come in handy. Do you spend hours of each day clearing your inbox or answering customer questions? If you’re like most people, you’ve probably underestimated just how much time some of your tasks take.

Repetitive tasks. Look for repeated tasks that follow a similar pattern each time you perform them. Think like Henry Ford; he saw that building cars was a repeatable process and came up with the moving assembly line method, revolutionizing production. You may not be building a physical product, but chances are you are producing something. It may be as simple as a social network update, or as complex as a new app. Look for the steps that are nearly identical each time, so you can build your own assembly line.

With all your tasks categorized, you can now see at a glance which are prime candidates for the DRY treatment. By definition, tasks labeled as repetitive are most likely to benefit from DRY. If a task isn’t repetitive, eliminate it from your list. Once you’ve done that, priority attention should be given to those tasks that hit the most categories.

Looking at the example in the image above, I scored each task 0-5 (5 being the highest) for each of the four categories. Then I totaled each task—the ones with the highest scores are the ones that are prime for the DRY treatment.

Eliminate Repetition at Work

Now you have a clear idea of which tasks would benefit from DRY, so it’s time to eliminate the repetition.

Tip 1: Create templates

The cornerstone of using DRY in your work life is the humble template. Whenever you create something, whether it’s an email, a business document, or an infographic, think if there’s something there you could save for future use. The time spent creating a template will save you exponentially more time down the road.

If the task seems too complex for a basic template, you may want to create a Standard Operating Procedure (SOP). Go through the task and break it down into its individual steps, which you can then either use as the basis for your own SOP, or delegate the task to someone else.

Here are the areas that are most ripe for templates:

With an estimated average of 31 business emails sent per day, the inbox is the center of the knowledge worker’s universe. But that also means it’s likely you’re sending the same emails over and over again.

Simply by lifting out all the personal information, you can create your own template and save it for future use. For more details on how to use templates within various email apps, read about automating your inbox.

If you send weekly updates to your manager, create specs for various stakeholders, or write tickets in your bug tracker, you likely spend a lot of time reinventing the wheel. Skim through your most recent communications and look for patterns—even a bare bones template will save you the hassle of formatting each time.

Proposals, contracts, invoices—they all look pretty similar. By removing the information specific to your clients and partners, you’ll have a template to work from and can tweak it for each use case.

If you give more than one presentation a year, make yourself a presentation template. Even if each presentation is vastly different, the skeleton can be the same.

Your templates are living documents. If you notice that you’re making the same change over and over, that means it’s time to update the template itself.

Tip 2: Find the right apps

Is there an app that can do the job for you?

The answer is almost certainly yes.

For example, maybe you’ve been writing your proposals in a word processor and emailing them as an attachment. As it turns out, there’s a wealth of proposal software that will streamline the process, sending beautifully designed proposals to your clients and letting you know once they’ve been reviewed. And while there’s nothing stopping you from creating an invoice template in Google Docs or Microsoft Word, invoicing software will take care of all the repetition, such as automatically numbering your invoices, keeping track of what’s been paid, and making your tax returns a whole lot simpler.

The same goes for basically anything, from scheduling meetings to creating surveys.

So if you find that, even with the best templates, you’re still regularly spending significant time manually adjusting them, it’s time to consider using an app. The right tool for the right job can mean the difference between an easy job or hammering a nail in with a screwdriver.

There’s even an app for templates—kind of. Text expanders make it easy to create various snippets of text that you can use again and again, no matter what app you’re in.

Tip 3: Automate your repetitive tasks

Once you have your suite of DRY apps picked out, you’ll notice something: Most of them are built to do one thing well. And having a dedicated tool to do a specific job makes a lot of sense. But your work is rarely that simple, and you might find yourself leaping from app to app in your daily workflow.

With Zapier, the apps you use most can talk to each other. Using automated workflows called Zaps, you can automatically send data between the apps, removing manual work from many of your daily tasks.

Depending on which tasks scored highest in your DRY assessment, you might want to create your own workflow, but here are a few ideas to get you started:

Принцип DRY на примере Laravel

Рассмотрим простой модуль, отвечающий за добавление новых пользователей.

И на его примере увидим, какие возможности открывает применение принципа DRY.

Для меня принцип DRY (Don’t Repeat Yourself) всегда воплощался в двух основных определениях:

На начальном этапе такое повторение кода кажется довольно безобидным.
Но мы уже имеем дублирование знаний, а знания дублировать запрещено.
Для этого обобщим создание пользователя в классе UserService

Переместив всю логику работы с моделью в сервис, избавляемся от ее дублирования в контроллере. Но у нас появляется другая проблема. Допустим, нам предстоит немного усложнить процесс создания пользователя.

Постепенно класс UserService начнет разрастаться и мы рискуем получить супер класс с огромным количеством зависимостей.

Класс единого действия CreateUser

Для того чтобы избежать таких последствий, можно разбить сервис на классы единого действия.

Основные требования к такому классу:

У нас уже есть проверка поля email в классе CreateRequet, но логично добавить проверку и сюда. Это более точно отображает бизнес логику создания пользователя, а также упрощает отладку.

Контроллеры обретают следующий вид

В итоге имеем полностью изолированную логику создания пользователя. Ее удобно изменять и расширять.

Теперь посмотрим какие преимущества нам дает такой подход.

Например, есть задача импортировать пользователей.

Получаем возможность повторного использования кода, встраивая его в метод Collection::map(). А так же обработать под наши нужды пользователей, чьи email адреса не являются уникальными.

Декорирование

Допустим нам необходимо регистрировать каждого нового пользователя в файл.

Для этого мы не будем встраивать это действие в сам класс CreateUser, а воспользуемся паттерном Декоратор.

Затем, используя IoC-контейнер Laravel, мы можем связать класс LogCreateUser с классом CreateUser, и первый будет внедрен каждый раз, когда нам понадобиться экземпляр второго.

Мы также имеем возможность вынести настройку создания пользователя с помощью переменной в файле конфигурации.

Вывод

Здесь приведен простой пример. Реальная польза начинает проявляться, как только начинает расти сложность. Мы всегда знаем, что код находится в одном месте и его границы четко определены.

Получаем следующие преимущества: предотвращает дублирование, упрощает тестирование
и открывает дорогу к применению других принципов и паттернов проектирования.

Dry don t repeat yourself

Don’t Repeat Yourself (DRY, рус. Не повторяйся) — это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Он был сформулирован Энди Хантом (англ.) и Дэйвом Томасом[убрать шаблон] в их книге The Pragmatic Programmer (англ.). Они применяли этот принцип к «схемам баз данных, планам тестирования, сборкам программного обеспечения, даже к документации». Когда принцип DRY применяется успешно, изменение единственного элемента системы не требует внесения изменений в другие, логически не связанные элементы. Те элементы, которые логически связаны, изменяются предсказуемо и единообразно. Помимо использования методов и функций в коде, Томас и Хант считают необходимым использование генераторов кода, автоматических систем компиляции.

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

Принцип DRY, известный также как Single Source of Truth (англ.), превалирует в Model Driven Architecture-системах, в которых артефакты программы извлекаются из главной модели объекта и выражаются в такой форме, как UML. Код, написанный по принципу DRY, создаётся с помощью конвертации данных и генераторов кода, которые позволяют разработчику ПО избежать операций вырезания, копирования и вставки. Обычно код, написанный по этому принципу, позволяет легче управлять большими информационными системами. Такие инструменты, как XDoclet (англ.) и XSLT являются примерами техник программирования DRY. Примерами систем, которые требуют дублирования информации, являются Enterprise Java Beans версии 2, которая требует не только дублирования в коде Java, но и в файлах конфигурации. Примерами систем, в которых сделана попытка устранить дублирование информации, являются фреймворки Symfony, web2py (англ.), Yii, Django, Ruby on Rails[3][4], а также среды разработки Visual Studio LightSwitch и Enterprise Java Beans версии 3.

DRY и WET

Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза). Это игра английских слов «dry» (рус. сухой) и «wet» (рус. влажный).