## Подкласс паттерна
Поведенческие паттерны проектирования
Поведенческие паттерны проектирования связаны с алгоритмами и распределением обязанностей между объектами.
Определение
Инкапсуляция запроса в виде объекта, что позволяет параметризовать клиентов с различными запросами и поддерживать отменяемые операции.
Превращает запрос в отдельный объект, содержащий всю информацию о запросе. Это преобразование позволяет передавать запросы в качестве аргументов метода, задерживать или ставить в очередь выполнение запроса, а также поддерживать отменяемые операции.
Имена Psudo
Действия, транзакция
Зачем нужен
- Предположим, вы создаете приложение для работы с текстовым редактором. Вы хотите создать набор инструментов пользовательского интерфейса, включающий такие объекты, как кнопки и меню, которые выполняют запрос в ответ на ввод пользователя.
- Только приложения, использующие этот набор инструментов, знают, что должно быть сделано с тем или иным объектом.
- Как разработчики инструментария мы не можем знать получателя запроса или операцию, которую он выполнит.
У вас есть общий класс Button, который можно использовать на панели инструментов, а также для общих кнопок на различных панелях инструментов.
Хотя все эти кнопки выглядят одинаково, они выполняют разные действия.
САМОЕ ПРОСТОЕ РЕШЕНИЕ — СОЗДАТЬ МНОЖЕСТВО ПОДКЛАССОВ ДЛЯ КАЖДОГО МЕСТА, ГДЕ ИСПОЛЬЗУЕТСЯ КНОПКА. ПОДКЛАССЫ ДОЛЖНЫ СОДЕРЖАТЬ КОД, КОТОРЫЙ БУДЕТ ВЫПОЛНЯТЬСЯ ПРИ НАЖАТИИ НА КНОПКУ.
Итак, что не так с этим подходом
- Вы имеете огромное количество подклассов
- код будет ломаться в подклассе в случае модификации базового класса Button
- некоторые логические операции, такие как копирование/вставка в данном случае в текстовом редакторе, придется вызывать из нескольких мест:
- Пользователь нажимает кнопку копирования на панели инструментов или копирует что-то с помощью CTRL+C или CMD+C
Решение
- Разделение проблем
- Разбить приложение на несколько слоев
Паттерн команды интуитивно говорит, что отправка запроса путем извлечения всех требований для принятия решения, таких как вызываемый объект, имя метода и список аргументов, в один класс команды с единственным методом, который вызывает запрос.
Архитектура команды:
Следующий шаг — заставить ваши команды реализовать один и тот же интерфейс. Обычно он состоит из единственного метода выполнения, который не принимает никаких параметров. Этот интерфейс позволяет вам использовать различные команды с одним и тем же отправителем запроса, не связывая его с конкретными классами команд. В качестве бонуса, теперь вы можете переключать объекты команд, связанные с отправителем, эффективно изменяя поведение отправителя во время выполнения.
Пример кода:
В случае, если приведенный выше пример не загрузился :
url редактора Stack Blits
url приложения Stack Blits