5 шаблонов проектирования, которые должен освоить каждый разработчик

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

Развитие разработчика похоже на превращение из потребителя продукта в его создателя. Допустим, вы используете React или Angular. Это условная точка А. Тут вы просто применяете готовые решения. Конечный пункт — точка Б: здесь вы уже сами создаёте то, чем пользуются другие разработчики.

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

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

Одиночка (Singleton)

Этот шаблон предполагает использование одного класса, который отвечает за создание объекта и гарантирует, что он единственный, — то есть предотвращает создание экземпляра вне класса. Класс предоставляет прямой доступ к объекту без необходимости создавать экземпляр объекта класса. Чаще всего «Одиночку» используют для контроля доступа к какому-либо общему ресурсу.

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

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

Этот шаблон часто применяют не по назначению. Он полезен тогда, когда класс должен иметь только один экземпляр — ни больше ни меньше. Но некоторые разработчики пытаются использовать «Одиночку» вместо глобальных переменных.

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

Фасад (Facade)

В обычной жизни фасад — это наружная часть здания, за которой прячется всё его содержимое: стены и перегородки, утепление, трубы, провода и прочее. У паттерна «Фасад» та же функция: с его помощью вы можете красиво «облицевать» свой код. Иначе говоря, «Фасад» — это структурный паттерн проектирования, который предоставляет простой интерфейс сложной системе классов, библиотеке или фреймворку.

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

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

Не перестарайтесь и с вертикальным масштабированием — иначе можно получить «фасад», привязанный к конкретному единичному случаю. Тогда он перестанет быть универсальным и окажется, по сути, бесполезным.

Мост (Bridge)

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

«Мост» может быть полезен, когда разработчики пытаются расширить подклассы в двух независимых измерениях. Это частая проблема при использовании наследования, и Bridge пытается решить её, переключая наследование на композицию.

В паттерне используется интерфейс, который выступает в роли моста между классами абстракции и классами реализации. Если говорить терминами разработчиков, интерфейс «Моста» — это что-то вроде API. Шаблон упрощает поддержку существующего кода и снижает риск его сломать.

Стратегия (Strategy)

С помощью этого паттерна можно определить семейство алгоритмов, затем поместить каждый из них в собственный класс (их называют стратегиями) и сделать их объекты взаимозаменяемыми.

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

Паттерн «Стратегия» упростит задачу: он перенесёт механизм получения доступа к сведениям о клиентах и рассылки сообщений и писем в инфраструктурный слой.

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

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

Наблюдатель (Observer)

Сейчас этот паттерн очень популярен, его применяют практически везде. «Наблюдатель» обеспечивает свободную связь между издателем (создающим события) и подписчиком или подписчиками (отслеживающими события) и может использоваться где угодно.

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

У этой проблемы есть два решения:

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

Заключение

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

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

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