Шаблоны проектирования — это высокоуровневые ответы на проблемы, с которыми мы, разработчики программного обеспечения, часто сталкиваемся. Это не код — повторяю, ЭТО НЕ КОД. Это похоже на объяснение того, как подойти к этим вопросам и найти решение.
Я понял, что одна из самых распространенных вещей, это то, что люди, получившие высшее образование в области компьютерных наук или другой области, связанной с ИТ, где преподавались шаблоны проектирования, забывают о них или находят их бесполезными в своей работе, если никогда не были достаточно обучены их использованию.
Тем не менее, это основные способности, которыми должны обладать все разработчики, главным образом потому, что по мере развития вашей карьеры в области разработки вы должны будете распознавать шаблоны и использовать их для создания микросервисов/систем/решений.
Есть несколько причин, по которым шаблон проектирования будет вам полезен
Проще говоря, шаблоны проектирования используются для облегчения задач.
- Например, при написании программы основным правилом объекта является то, что все атрибуты должны быть закрытыми и не могут быть доступны другим классам. Итак, как мы можем сделать наш код более читабельным и адаптируемым? Вы можете использовать Порождающие шаблоны проектирования, чтобы очистить свой код.
- Другая причина заключается в том, что шаблоны проектирования создают общий словарь, который вы и ваши коллеги можете использовать для более эффективного общения. Вы можете заметить: «О, просто используйте для этого синглтон», и все поймут ваш совет. Если вы уже знаете шаблон и его название, нет необходимости объяснять, что такое синглтон.
Я исследовал множество шаблонов проектирования и использовал некоторые из них в личных и рабочих проектах.
Итак, в этой статье я поделюсь своими тремя лучшими шаблонами проектирования, все из которых просты для изучения и использования в вашей работе/личных проектах.
Итак, выпейте чашечку кофе и наслаждайтесь чтением!
1. Стратегия (Strategy Design Pattern)
Это мой любимый шаблон всех времен.
Этот шаблон позволяет переключаться между методами для конкретной задачи во время выполнения без ведома клиента. Вместо того, чтобы напрямую реализовывать один метод, коду в рантайме даются инструкции, которые сообщают ему, какой из группы алгоритмов следует запускать.
«Принцип открытости/закрытости», утверждающий, что базовый код должен быть открыт для расширения, но закрыт для модификации, был одним из жизненно важных принципов, о которых я узнал на четвертом курсе университета.
Один из способов реализовать принцип открытости-закрытости — использовать шаблон стратегии.
Когда требуется множество алгоритмов для одной стратегии (интерфейса), пригодится этот шаблон. Реализация этого шаблона требует четырех элементов, включая клиента:
- Клиент -> Это место, где используется контекст
- Контекст -> ситуация, в которой алгоритм выбирается во время выполнения
- Интерфейс -> стратегия
- Алгоритм -> реальное применение
Давайте посмотрим на пример.
Предположим, вы создали приложение для бизнеса, которое позволяет отправлять посылки ближайшим клиентам. Первая версия приложения включала доставку велосипедами, которая имела огромный успех. Доставка на велосипеде больше не является надуманной альтернативой, когда ваша компания расширяется по всему городу.
Теперь компания попросила вас создать функцию, позволяющую доставлять посылки на машине. Это было только начало.
Позже вам было приказано добавить поезда, а еще позже — авиа. Класс PackageDelivery увеличивается в размерах, и управление им становится все сложнее по мере добавления новых алгоритмов. Любая незначительная ошибка в классе может поставить под угрозу функциональный код, что потребует повторного тестирования всего приложения, даже если проблема была только с одним из алгоритмов.
В результате на помощь приходит шаблон Стратегии, в котором говорится, что эти алгоритмы должны быть разделены на независимые классы, называемые стратегиями. Таким образом, вам не придется менять основной курс в следующий раз, когда вы захотите добавить корабли в качестве опции.
Псевдокод ниже показывает, как основной класс использует эту тактику для передачи посылок различными способами.
2. Одиночка (Singleton Design Pattern)
Существует только один экземпляр класса.
Шаблон Одиночка используется, когда требуется только один экземпляр класса. Основной причиной ограничения создания экземпляров класса является сохранение контроля над общими ресурсами, такими как базы данных, хранилища и файлы. С помощью этого метода мы создаем экземпляр класса и предоставляем этому экземпляру глобальный доступ.
Для всего, что запускается с помощью ключа API, я использовал синглтон в качестве источника параметров конфигурации для клиентского веб-приложения, а также для хранения данных в памяти в клиентском веб-приложении с помощью Flux.
Поскольку синглтонам не нужно состояние, они используются для реализации компараторов. Поскольку мы просто строим одну модель, мы можем экономить память.
Чтобы дать вам представление, вот фрагмент JavaScript кода, который я написал в качестве примера:
Многие из нас и многие из вас, возможно, по разным причинам ограничивали создание экземпляров класса и только сейчас поняли, что все это время это был шаблон проектирования!
3. Наблюдатель (Observer Design Pattern)
Я дам вам лишь поверхностное описание этого шаблона.
В основе этого шаблона проектирования лежит отношение «один ко многим» между многочисленными объектами. Это позволяет вам настроить механизм подписки, который позволяет другим объектам получать оповещения о каждом появлении объекта, на который вы подписаны.
Kafka, RabbitMQ, Amazon SNS и NATS — это некоторые реальные примеры систем публикации/подписки, которые реализуют шаблон издатель/подписчик (вариант Observer).
Ниже приведены некоторые примеры работы этого шаблона:
- В мире веб-разработки, особенно с React, вы слышали о Redux для управления состоянием вашего приложения. Redux — это реализация шаблона Наблюдатель. Когда вы прикрепляете действие для обновления состояния хранилища, компоненты, прослушивающие изменения, соответствующим образом корректируют свои представления.
- Если код отправлен в удаленный репозиторий, среда CI отслеживает его изменения и выполняет сборку.
- Процедурное программирование, управляемое событиями, используется для имитации шаблона Наблюдатель. Как и другие шаблоны проектирования, этот шаблон позволяет нам определять слабосвязанные системы. Используя эту технику, мы можем разрабатывать поддерживаемое и модульное программное обеспечение. Мы также можем достичь очевидной сегментации между отдельными участниками в системе, управляемой событиями.
Всегда ли использование шаблонов проектирования является хорошей идеей?
Широко признано, что шаблоны проектирования обеспечивают значительные преимущества. Однако при чрезмерном употреблении возникают нежелательные побочные эффекты.
Поэтому разработчикам следует подумать, является ли использование шаблонов проектирования эффективным и подходящим для проекта, а также поискать альтернативные решения и сравнить их с шаблонами проектирования. Тем не менее, каждый инженер-программист должен знать о шаблонах проектирования, их формах и наиболее популярных подходах.
Я не понимаю, что не так с людьми: они учатся заучивая наизусть или как-то еще, но не понимая. Их понимание так слабо! — Ричард Фейнман.
Я встречался со многими инженерами на различных технических мероприятиях и в Интернете, и я обычно поднимаю тему шаблонов проектирования, когда мы говорим о разработке программного обеспечения.
Я заметил, что некоторые инженеры, которые запоминают шаблоны проектирования, считают, что овладели каким-то мистическим заклинанием, которое теперь могут использовать где угодно. Понимание шаблонов проектирования — это не то же самое, что просто знать их имена.
Вот почему так важно понимать присущие любому шаблону ограничения и компромиссы, прежде чем его применять.
Начало шаблонов проектирования
Если вам интересно узнать о происхождении шаблонов проектирования, этот раздел для вас. Так что продолжайте читать!
Архитектор Кристофер Александер первым предложил идею шаблонов проектирования, которую он описал в своей книге «Вневременный способ строительства». Если вы хотите знать, что происходит, я рекомендую читать прямо в этом источнике. За ним последовал «Язык шаблонов», превосходное руководство по разработке шаблонов. Пожалуйста, не верьте мне на слово, поищите сами.
Эти идеи набрали обороты в течение следующих нескольких лет. В 1994 году «Бригада четырех» (Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссайдс), группа исследователей в области разработки программного обеспечения, опубликовала книгу «Приемы объектно-ориентированного проектирования. Паттерны проектирования», которая до сих пор находится на книжных полках многих инженеров-программистов.
Эта книга считается «публичным дебютом» шаблонов проектирования в сообществе разработчиков, и до сих пор она влияет на развитие шаблонов проектирования.
Выводы
Надеюсь, мой пост о трех наиболее распространенных шаблонах проектирования был вам полезен. Существует гораздо больше паттернов, и в книге «Шаблоны проектирования» есть иллюстрации и описания.
Я хочу отметить, что я написал всего 3-4 страницы текста, по сравнению с 406 страницами «Погружения в шаблоны проектирования» и «Паттернами проектирования». Вполне вероятно, что я рассмотрел не все или неверно истолковал некоторые моменты.
Это напоминает мне, что мне нужно вернуться и прочитать «Вневременный способ строительства».
Вместо того, чтобы верить мне на слово, прочитайте вышеупомянутые книги и скажите мне, что, по вашему мнению, я упускаю.
Ваше здоровье!