какие шаблоны программирования вам известны и как их можно реализовать

Шаблоны проектирования простым языком. Часть третья. Поведенческие шаблоны

Авторизуйтесь

Шаблоны проектирования простым языком. Часть третья. Поведенческие шаблоны

Шаблоны проектирования — это руководства по решению повторяющихся проблем. Это не классы, пакеты или библиотеки, которые можно было бы подключить к вашему приложению и сидеть в ожидании чуда. Они скорее являются методиками, как решать определенные проблемы в определенных ситуациях.

Википедия описывает их следующим образом:

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

Будьте осторожны

Также заметьте, что примеры ниже написаны на PHP 7. Но это не должно вас останавливать, ведь принципы остаются такими же.

Типы шаблонов

Шаблоны бывают следующих трех видов:

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

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

Цепочка обязанностей (Chain of Responsibility)

Цепочка обязанностей — поведенческий шаблон проектирования предназначенный для организации в системе уровней ответственности.

Пример из жизни: например, у вас есть три платежных метода (A, B и C), настроенных на вашем банковском счёте. На каждом лежит разное количество денег. На A есть 100 долларов, на B есть 300 долларов и на C — 1000 долларов. Предпочтение отдается в следующем порядке: A, B и C. Вы пытаетесь заказать что-то, что стоит 210 долларов. Используя цепочку обязанностей, первым на возможность оплаты будет проверен метод А, и в случае успеха пройдет оплата и цепь разорвется. Если нет, то запрос перейдет к методу B для аналогичной проверки. Здесь A, B и C — это звенья цепи, а все явление — цепочка обязанностей.

Простыми словами: цепочка обязанностей помогает строить цепочки объектов. Запрос входит с одного конца и проходит через каждый объект, пока не найдет подходящий обработчик.

Обратимся к коду. Приведем пример с банковскими счетами. Изначально у нас есть базовый Account с логикой для соединения счетов цепью и некоторые счета:

Теперь приготовим цепь, используя объявленные выше звенья (например, Bank, Paypal, Bitcoin):

Команда (Command)

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

Пример из жизни: Типичный пример: вы заказываете еду в ресторане. Вы (т.е. Client ) просите официанта (например, Invoker ) принести еду (то есть Command ), а официант просто переправляет запрос шеф-повару (то есть Receiver ), который знает, что и как готовить. Другим примером может быть то, что вы ( Client ) включаете ( Command ) телевизор ( Receiver ) с помощью пульта дистанционного управления ( Invoker ).

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

Старт 22 ноября, 4 месяца, Онлайн, От 35 000 до 100 000 ₽

Наконец, мы можем увидеть, как использовать нашего клиента:

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

Итератор (Iterator)

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

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

Простыми словами: Представляет способ доступа к элементам объекта без показа базового представления.

Обратимся к примерам в коде. В PHP очень просто реализовать это, используя SPL (Standard PHP Library). Приводя наш пример с радиостанциями, изначально у нас есть Radiostation :

Затем у нас есть итератор:

Посредник (Mediator)

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

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

Простыми словами: Шаблон посредник подразумевает добавление стороннего объекта (посредника) для управления взаимодействием между двумя объектами (коллегами). Шаблон помогает уменьшить связанность (coupling) классов, общающихся друг с другом, ведь теперь они не должны знать о реализациях своих собеседников.

Разберем пример в коде. Простейший пример: чат (посредник), в котором пользователи (коллеги) отправляют друг другу сообщения.

Изначально у нас есть посредник ChatRoomMediator :

Затем у нас есть наши User (коллеги):

Хранитель (Memento)

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

Пример из жизни: В качестве примера можно привести калькулятор (создатель), у которого любая последняя выполненная операция сохраняется в памяти (хранитель), чтобы вы могли снова вызвать её с помощью каких-то кнопок (опекун).

Простыми словами: Шаблон хранитель фиксирует и хранит текущее состояние объекта, чтобы оно легко восстанавливалось.

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

Затем у нас есть наш Editor (создатель), который будет использовать объект хранитель:

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

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

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

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

Затем мы делаем публикации JobPostings на которые соискатели могут подписываться:

Посетитель (Visitor)

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

Пример из жизни: Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон посетитель помогает добавлять места для посещения.

Простыми словами: Шаблон посетитель позволяет добавлять будущие операции для объектов без их модифицирования.

Затем у нас есть реализация для животных:

Давайте реализуем посетителя:

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

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

Стратегия — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.

Пример из жизни: Возьмём пример с пузырьковой сортировкой. Мы её реализовали, но с ростом объёмов данных сортировка работа стала выполняться очень медленно. Тогда мы сделали быструю сортировку. Алгоритм работает быстрее на больших объёмах, но на маленьких он очень медленный. Тогда мы реализовали стратегию, при которой для маленьких объёмов данных используется пузырьковая сортировка, а для больших объёмов — быстрая.

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

Перейдем к коду. Возьмем наш пример. Изначально у нас есть наша SortStrategy и разные её реализации:

Состояние (State)

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

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

Простыми словами: Шаблон позволяет менять поведение класса при изменении состояния.

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

Изначально у нас есть интерфейс WritingState и несколько его реализаций:

Паттерн состояние применяется в проектировании распределённых сиситем, наряду с другими паттернами.

Шаблонный метод (Template Method)

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

Пример из жизни: Допустим, вы собрались строить дома. Этапы будут такими:

Порядок этапов никогда не меняется. Вы не настелите крышу до возведения стен и т. д. Но каждый этап модифицируется: стены, например, можно возвести из дерева, кирпича или газобетона.

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

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

Источник

Как вы освоили шаблоны проектирования?

1. Открываете папку с паттерном.
2. Читаете README.md с описание задачи.
3. Открываете exercise.php и пытаетесь решить задачу, применив соответствующий паттерн.
4. При необходимости вспоминаете теорию: github.com/domnikl/DesignPatternsPHP
5. Сверяетесь с решением в solution.php.

Когда начался бум и восторг вокруг концепции паттернов проектирования, выкрики «GoF рулит!» и так далее, я озадачился тем, чтобы понять, что за шум?

По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The «Gang of Four») в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

К изучению паттернов я дам такие советы:

2) Постарайтесь осознать, доводилось ли вам сталкиваться в работе раньше с чем-то, что является или могло бы легко стать одним из шаблонов. Где получалось применить концепт верно, а где из-за этого только проблемы были.

Источник

В обзорном исследовании 2020 года Wedyan и Abufakher изучают шаблоны проектирования и качество программного обеспечения и приходят к выводу: «Наше исследование показало, что первичные исследования предоставляют эмпирические данные о положительном влиянии документации экземпляров шаблонов проектирования на понимание программы и, следовательно, на ремонтопригодность. Хотя этот результат неудивителен, он, тем не менее, имеет два признака. Во-первых, разработчикам следует приложить больше усилий, чтобы добавить такую ​​документацию, даже если в форме простых комментариев в исходный код. Во-вторых, при сравнении результатов различных исследований влияние документации необходимо учитывать «.

СОДЕРЖАНИЕ

История

Узоры возникла как архитектурная концепция по Кристоферу Александеру еще в 1977 г. (ср «Узор улиц,» Журнал AIP, сентябрь, 1977, т. 32, № 3, стр. 273-278). В 1987 году Кент Бек и Уорд Каннингем начали экспериментировать с идеей применения шаблонов в программировании, особенно в языках шаблонов, и представили свои результаты на конференции OOPSLA в том же году. В последующие годы Бек, Каннингем и другие продолжили эту работу.

Хотя шаблоны проектирования применяются практически давно, формализация концепции шаблонов проектирования томилась на несколько лет.

Упражняться

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

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

Состав

Шаблоны для конкретных доменов

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

Классификация и список

Созидательные шаблоны

Структурные образцы

МаркерПустой интерфейс для связывания метаданных с классом.НетНетЭффективная JavaМодульСгруппируйте несколько связанных элементов, таких как классы, синглтоны, методы, используемые во всем мире, в единую концептуальную сущность.НетНетN / AПроксиПредоставьте суррогат или заполнитель для другого объекта для управления доступом к нему.даНетN / AБлизнецTwin позволяет моделировать множественное наследование на языках программирования, которые не поддерживают эту функцию.НетНетN / A

Поведенческие модели

Шаблоны параллелизма

Документация

Критика

Неправильное использование шаблонов может излишне усложнять.

Источник

Шаблоны проектирования в автоматном программировании

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

В статье рассматриваются особенности применения шаблонов Visitor/Double Dispatch и State при реализации системы на основе конечного автомата. Кроме того, статью можно рассматривать как продолжение цикла публикаций о шаблонах проектирования на Хабрахабре.

Мотивация

Автоматное программирование — весьма удобный и гибкий инструмент, который позволяет решать поставленную задачу в терминах, близких понятиям предметной области. Например, задача о программировании поведения лифта в многоэтажном доме превращается в весьма формализованную модель автомата со следующим состояниями: “Лифт едет вверх”, “Лифт едет вниз”, “Лифт стоит на этаже N” и приходящими от жильцов дома событиями: “Нажата кнопка Вниз на N-ом этаже” и “Нажата кнопка Вверх на N-ом этаже”.

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

Для решения этой проблемы существует ООП и шаблоны Visitor и State.

Пример

Рассмотрим следующую задачу. Пусть требуется спроектировать и реализовать примитивную автомагнитолу, которая поддерживает два режима работы — “радио” и “CD-плеер”. Переключение между режимами осуществляется с помощью тумблера на панели управления (см. рисунок в начале статьи). Кроме того, магнитола поддерживает механизм переключения радиостанций или треков (кнопка “Next”), в зависимости от выставленного режима.

Отличный пример того как данная задача решается на основе вложенных ветвлений (switch) языка Си можно посмотреть в Википедии. Рассмотрим его наиболее значимый участок.

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

Шаблон Visitor и его частный случай Double Dispatch призван решить данную проблему, путем разделения понятий состояния и обработчика. При этом, конечная реализация алгоритма обработки события выбирается в процессе исполнения, на основе двух факторов: типа события и типа обработчика (отсюда название — “Двойная Диспетчеризация”).

Таким образом, для добавления нового типа события или обработчика в систему, достаточно лишь реализовать требуемый класс, наследника классов “Событие” или “Обработчик” соответственно.

Диаграмма классов

Наибольший интерес в рассмотренной диаграмме представляет интерфейс GramophoneHandler, который одновременно является частью конструкции Visitor (в качестве самого посетителя) и самодостаточной конструкцией State (в качестве состояния для Gramophone). Т.е. можно считать, что в рассмотренном примере используется своего рода композиция двух шаблонов.

Реализация

Один из вариантов использования системы будет выглядеть следующим образом:

Опишем возможные варианты внешних событий, приходящих системе.

В рассмотренном коде, метод apply() имеет одинаковую реализацию во всех потомках. В этом заключается основная идея шаблона — полиморфное определение типа события в процессе исполнения кода. Т.е. у обработчика будет вызываться метод handle() в зависимости от типа самого события (типа ссылки this).

В языках, не поддерживающих полиморфизм (например в JavaScript), можно инкапсулировать информацию о типе обрабатываемого события в названии метода. Тогда в нашем случае методы буду выглядеть как handleNext(event) и handleToogle(event) а вызывающий код так:

Реализация возможных состояний системы представляет собой следующий код. В нашем случае состояние = обработчик.

Наконец расмотрим реализацию основного класса системы — магнитолы (Gramophone).

В рассмотренной реализации методы toogle(), nextTrack() и nextStation() имеют область видимости только внутри пакета. Это сделано для того, чтобы обезопасить систему от прямых внешних вызовов. Более того, в реальных условиях рекомендуется дополнительно проверять природу вызывающего потока. Например в каждый из методов можно добавить следующий код проверки.

Кроме того, следует обратить внимание на метод run(), который реализует идиому Event Loop. В данном случае, метод содержит два вложенных цикла, обеспечивающих засыпание потока при отсутствии событий в очереди. При этом, добавление каждого нового события в очередь (см. метод dispatch()) его пробуждает.

Заключение

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

Код рассмотренного примера доступен на GitHub. Там же можно найти примеры на другие паттерны, о которых уже было написано несколько статей на Хабрахабре.

Источник

Для чего нужны шаблоны проектирования

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

Немного воспоминаний из молодости

Когда я учился в университете, нам преподавали в рамках одного из курсов шаблоны проектирования. На тот момент они казались мне чем-то наподобие сферического коня в вакууме, потому что практического опыта их применения я не имел (это был третий или начало четвертого курса много лет назад). Запомнить кто из них кто тоже было достаточно сложно, не говоря уже о тонкостях и деталях. Тем не менее, вопросы по шаблонам проектирования задавали в обязательном порядке на каждом собеседовании на работу. Кандидатам приходилось раздувать щеки и доказывать как круты разные шаблоны (особенно Singleton), видя их в жизни максимум раз-другой на страницах книжек.

Но ведь совсем не глупые люди придумали шаблоны проектирования:

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

Через некоторое время работы я начал замечать, что даже теоретические знания шаблонов проектирования помогают мне понять чужой код гораздо быстрее. А это особенно важно на старте вашей карьеры, когда вам надо вникать в существующие проекты без опыта работы. Например, встречая класс с суффиксом Builder, я понимал, что его добавили с целью упрощения и изоляции логики построения сложных объектов. Я сразу легко находил как им пользоваться и применять в своем коде. Повсюду были разбросаны представители шаблона Singleton, совершить ошибку при инициализации которых так легко без знаний правил применения. В коде, с которым я работал, обильно встречались Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method и прочие популярные шаблоны проектирования.

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

А как без шаблонов?

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

Первый важный параметр — это время, которое тратится на обсуждение и принятие решения (я надеюсь, что у вас решения принимает не один бородатый Senior Senior Global Product Software Architect). Представьте себе как сложно было бы быстро объяснить кому-то, что нужно реализовать Decorator: «нам нужно сделать класс, которому мы передадим в конструкторе экземпляр другой реализации того же интерфейса и который будет добавлять логику к вызову этих методов, не меняя их основного поведения. » А ведь еще за кадром остались куча мелочей и нюансов. И это для мелкой детали вашего дизайна, которых в большинстве решений десятки, а то и сотни. Мы даже не трогаем сложные и серьезные архитектурные шаблоны.

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

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

В жизни мы активно используем примеры для описания ситуаций, предметов, поступков. Чтобы объяснить кому-то какую-то концепцию, мы базируемся на общеизвестных знаниях и выстраиваем примеры на их основе. «Такой же здоровый как Вася», «так же тяжело как после 5 км пробежки», «плохо как с бодуна», «кислый как лимон» и т.д. Подобные выражения мы используем в своей речи постоянно и даже не замечаем этого. Для нас их применение проще чем детальное описание и это позволяет вашему собеседнику лучше вас понять.

Следующий уровень

Если вы заметили, что вы не пытаетесь вспомнить детали реализации шаблона проектирования, а просто можете изложить детали его применения своими словами, то вы переросли уровень Shu в известной восточной философии Shuhari (я когда-то давно писал о ее применимости к Agile подходам и практикам). На уровне Shu вы просто следуете шаблонам и не можете осознать их полезность, тонкости и влияние. На уровне Ha вы уже все осознаете и можете сознательно отказываться от определенных шаблонов, критиковать решения на их базе, видоизменять некоторые шаблоны под конкретную ситуацию и контекст.

На уровне Ha я настоятельно рекомендую прочитать отличную книгу «Refactoring to Patterns» от Джошуа Кериевски. В ней рассказывается о том, как находить в коде неподходящие или плохо примененные шаблоны проектирования, а потом посредством рефакторинга приводить их к верным и подходящим решениям. Эту книгу стоит читать именно на уровне Ha, потому что до этого она будет для вас просто пустым звуком.

У как же уровень Ri? На этом уровне вы и вовсе перестаете задумываться о применении шаблонов. Решения рождаются натурально на базе ваших знаний и навыков, которые вы накопили с годами. Где-то вырисовываются одни шаблоны, где-то ваши собственные наработки, которые стали для вас шаблонами в данном контексте. В голове у вас перестает работать цепочка «от шаблона к решению» и остается только «от решения к шаблону». Тогда вместо вопросов о конкретных шаблонах проектирования на собеседовании вы переходите к открытым вопросам о применимости данного инструмента и примерах из реальной жизни…

Заключение

Шаблоны проектирования — это один из инструментов разработчика, который помогает ему сэкономить время и сделать более качественное решение. Как и любой другой инструмент, в одних руках он может принести много пользы, а в других — один только вред. Я попытался донести на примерах, что конкретно дадут вам шаблоны проектирования и как к ним стоит относиться. Надеюсь, мне это удалось…

Источник