Java 8 vs GoF: Command

До недавнего времени я считал паттерны проектирования некими незыблемыми постулатами, которые нужно знать на память как и таблицу ASCII (шутка). Но о чем я не подозревал, так это о том, что некоторые паттерны были рождены только потому, что на тот момент некий язык программирования просто не имел необходимого функционала для решения определенной задачи. И, как оказалось, с развитием языков программирования зарекомендовавшие себя подходы к решению стандартных задач могут претерпевать некие изменения или же вообще становиться антипаттернами. Возможно название заметки чересчур воинственное, т. к. в некоторых случаях новые возможности Java 8 не столько противопоставляются шаблонам проектирования, сколько совершенствуют их. Давай посмотрим с точки зрения Java 8 на шаблоны проектирования, некогда описанные бандой четырех. Погнали!

Начнем наше путешествие с паттерна “Команда”. Давай вспомним зачем он нужен. Команда - это поведенческий шаблон проектирования основной задачей которого является отделение инициатора операции от ее исполнителя. Такой подход позволит нам инкапсулировать запрос на действие в виде объектов и передавать их клиентам, отменять последние действия, а также организовывать их в очередь. Вот последнее мы как раз и реализуем. В качестве примера рассмотрим необходимость дистанционного управления освещением в доме.

Давай быстренько вспомним диаграмму команды.
Вроде более менее понятно. Начнем непосредственно с системы освещения (Receiver).


Теперь замутим немного команд.





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


Пульт готов. Пора бы счастливому обладателю (Client) нашего пульта настроить его и попробовать в действии.


Неплохо! Всего одной кнопкой мы включили свет, установили теплый оранжевый цвет и сделали его тусклым. Идеальный вариант для приятного вечера! Но что же такого особенного нам может предложить Java 8 в данном случае?

Для начала давай подрихтуем наш пульт.


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

А как тебе идея избавиться от всех этих классов команд? Ведь команда - это по сути действие, инкапсулированное в объект,  которое нам нужно передать из одного места в другое. Применяя лямбды мы можем полностью отказаться от классов оберток.


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


P. S. На данную заметку меня сподвиг доклад Николая Алименкова The modern view on classic design patterns. Так же очень советую посмотреть его примеры новых реализаций паттернов на GitHub.

Comments

Popular posts from this blog

JEEConf 2017 How it was

Java 8 vs GoF: Strategy

Separate and rule your tests