В своей статье, посвященной паттернам ООП, сайт proglib.io предлагает простыми словами поговорить о паттернах поведения, описывающих, как должны происходить процессы с несколькими вариантами развития событий.
Chain of responsibility (цепочка обязанностей)
Простейший пример цепочки обязанностей – процесс получения любого официального документа. Допустим, вам нужно получить некую справку из банка. Вы приходите в отделение рядом с домом, но там только выдают и принимают деньги. Вы идете в более крупное отделение города, но оказывается, что там такие справки не выдаются. Так происходит, пока вы не добираетесь до регионального отделения, где вам, наконец, могут дать нужную справку.
Таким образом сформирована «цепочка обязанностей», отдельные объекты которой обрабатывают ваш запрос. Запрос может быть обработан и в первом отделении, в зависимости от типа запроса и объектов, которые его обрабатывают.
Command/action (команда/действие)
Паттерн «Команда» похож на то, как работают выключатели света в наших домах. Каждый выключатель делает простое действие – соединяет или разъединяет два контакта. Что стоит за этими контактами выключателю неизвестно. Этот паттерн просто определяет общие правила для объектов, без необходимости описания всей подоплеки. Благодаря этому, одним типом выключателей можно взаимодействовать как с освещением, так и с чайником.
Iterator (итератор, указатель)
«Итератор» предоставляет правила доступа к списку объектов вне зависимости от их типа. Пример в реальной жизни – школьная шеренга на физкультуре, рассчитывающаяся на первый-второй. Часто, этот паттерн используется для доступа к другому – «реестру».
Mediator (посредник)
Вернемся к примеру из паттерна «одиночка» – телефонной станции. Ее можно рассматривать в качестве релевантного примера и для данного паттерна. Однако есть различия: «посредник» должен еще и управлять своей группой. Если вернуться к примеру со строем, то «медиатором» в нем будет командир, отдающий приказы.
Specification (спецификация, определение)
Этот паттерн описывает, подходит ли данный объект по параметрам. К примеру, нужно погрузить на судно грузовые контейнеры. Чтобы понять, нужно ли грузить конкретный контейнер, нам нужно выбрать метод, который будет это определять – этот процесс будет реализован паттерном «спецификация». В простейшем случае для каждого контейнера в «спецификации» мы определим страну назначения и если она будет совпадать со страной прибытия корабля – будем грузить. Таким образом, один раз вводится правило «сравнить две страны назначения», которое будет применяться ко всем кораблям и контейнерам.
Subsumption (категоризация)
Является прямым следствием «спецификации». Позволяет распределять объекты по категориям на основе определенных условий. Примером категоризации по аналогии с контейнерами и кораблями будет то, какие контейнеры в какие страны направляются.
Memento (хранитель)
Вспомните тот момент, когда вы просили знакомого человека рядом записать в свой мобильный номер, который вам диктуют по телефону. В этот момент ваш товарищ реализовал паттерн «хранитель».
В общих случаях он нужен, когда какому-то объекту требуется сохранить свое состояние в другом объекте и при необходимости восстановить его.
Observer или Listener (наблюдатель, слушатель)
Данный паттерн – это подписка на событие. К примеру, если вы подписаны на смс или email рассылку – ваш телефон или почтовый ящик реализует паттерн «Listener».
Blackboard (доска объявлений)
Данный паттерн является расширением предыдущего. Blackboard позволяет централизовано обслуживать как «наблюдателя», так и создателя событий. По аналогии с прошлым примером, этот паттерн реализует сам сайт, на котором был подписан пользователь и который генерирует рассылки.
Servant (слуга)
Servant служит для предоставления группе объектов общего функционала. Например, сайт с рассылкой из прошлого примера может быть для своих пользователей еще и «слугой», предоставляя, например, на главной странице информацию о точном времени или погоде, помимо основной рассылки.
Visitor (посетитель)
«Посетителя» легко понять, если представить стационарное обследование в больнице. Здесь посетителями будут врачи, которые приходят к пациенту и осматривают его. Мы можем использовать один и тот же алгоритм, чтобы отправлять разных врачей к разным пациентам.
Single-serving visitor (одноразовый посетитель)
Частный случай предыдущего паттерна. В рамках прошлого примера, врач будет не один и тот же, а каждый раз другой. То есть, мы отправляем к пациенту не врача, который работает в больнице, а каждый раз нанимаем самостоятельного доктора, который делает свою работу, получает плату и уходит.
Hierarchical visitor (иерархический посетитель)
Это тот же врач-«посетитель», только он отправляется в больницу и обходит всех больных, а не только одного.
State (состояние)
Можно привести в качестве аналогии внутреннее состояние человека – оно может быть разным в разный момент времени. Например, человек пришел с работы и получил запрос «Сходить в магазин». Такой запрос вызовет негативную выдачу «не пойду». Однако, если завтра человеку никуда не надо, возможно, он захочет купить в магазине не только хлеб насущный и результат обработки запроса будет ровно противоположным. Итого: один объект, один запрос, разные результаты. Для определения результата и используется «состояние».
Strategy (стратегия)
Человек приходит в магазин и имеет такие входные условия: нужно много, денег мало. В таком случае поиск нужных товаров займет много времени, чтобы они подошли по цене. В случае, если нужно много и денег тоже много, то в корзину будут попадать первые приглянувшиеся товары и времени на покупки уйдет меньше. Этот человек в магазине реализовывает паттерн «стратегия»: в зависимости от заданных параметров он выбирает стратегию расходования ресурсов для выполнения задачи.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]