За что отвечает паттерн mediator хочу заменить этот вопрос
Использование паттерна mediator для переключения между activity
В простейшем случае для запуска Activity в Android нужно создать Intent c указанием класса вызываемого activity и Bundle из параметров. И всё хорошо, пока у нас в приложении пара экранов. Сложности начинаются тогда, когда количество экранов в нашем приложении будет исчисляться десятками. В данной статье я бы хотел предложить относительно несложный способ организации работы с большим количеством Activity.
Введение
Для того, что бы разговор был более предметным, будем считать, что в нашем приложении есть по крайней мере 3 активити:
Проблема
Что является главным недостатком стандартного подхода, при котором экземпляры Intent создаются прямо в коде Activity. Это дублирование кода. Если мы захотим добавить к вызову активити ещё один параметр, нам придётся изменить все места, где это активити вызывается. Если приложение разрабатывается более чем одним человеком, то придётся оповестить всю команду о сделанных изменениях. Если потребуется заменить одно активити другим, потребуется опять-таки искать все вхождения. И пускай такую работу за нас может выполнить IDE, все равно это не фен-шуй.
Решение
Реализация
Диаграмма классов приведена в начале статьи. Сначала рассмотрим каждый из классов подробнее.
Класс MyIntent хранит константы для параметров вызова activity.
Класс ActivityMediator реализует вывоз активити по данному классу. Конструктор принимает текущее активити и сохраняет в приватное поле. Два защищённых метода вызывают активити по данному классу без экстра или с ним. Защищёнными эти методы сделаны для того, что бы избежать соблазна вызывать их напрямую.
От класса ActivityMediator наследуем класс MyActivityMediator.
Класс MyActivity — абстрактный, от него наследуются все остальные активити в проекте.
Теперь в любом активити нашего приложения мы можем вызвать любое другое активити. Например, так можно вызвать редактор для создания нового документа:
Управление зависимостями, события и паттерны Observer и Mediator
Паттерны в чистом виде встречаются довольно редко и при изучении паттернов, особенно на ранних этапах, важны не столько сами паттерны, сколько понимание механизмов (тактик), с помощью которых они реализуются. В этой статье я хотел бы описать один из таких механизмов (управление зависимостями), который используется в паттернах Observer и Mediator, но который часто упускается из внимания. Если ты только начинаешь изучать паттерны, то добро пожаловать под кат.
Управление зависимостями
Начнём с утверждения: если класс A зависит от класса B, то, не меняя поведения, можно переписать код так, что класс B будет зависеть от класса A или ввести ещё один класс C таким образом, что классы A и B будут независимы, а класс C будет связывать и зависеть от классов A и B.
Один класс зависит от другого, если он обращается к его полям или методам. Поля легко переносятся из одного класса в другой, поэтому остановимся подробнее на методах. Допустим, класс B содержит метод Print, который выводит текущую дату в консоль, а класс А вызывает этот метод.
Таким образом класс A зависит от класса B. Чтобы вывернуть эту зависимость, вместо вызова метода Print напрямую, сгенерируем событие. Теперь класс А ничего не знает о классе B, а класс B может подписаться на событие класса A. Т.е. класс B будет зависеть от класса A.
Поведение кода не меняется, а в вызывающем методе меняется только порядок инициализации объектов и передача зависимостей в конструктор.
По сути, это и есть реализация паттерна Observer в C#. Класс A — это обозреваемый объект (Observable), а класс B это обозреватель (Observer). Класс A является независимым классом, который генерирует уведомления (события). Другие классы, которые в этом заинтересованы, могут подписываться на эти события и выполнять свою логику. Система становится более динамичной за счёт того, что теперь классу A не нужно знать о других реализациях. Мы можем добавлять новые реализации, которые будут подписываться на события, при этом класс A будет оставаться неизменным.
Можно пойти дальше и убрать зависимость класса B от A, добавив внешний код, который будет связывать эти два класса, т.е. подписывать один объект на события другого.
Теперь классы A и B полностью независимы, каждый выполняет свою задачу и ничего не знает о других классах. Логика по взаимодействию между объектами уходит в новый класс. Только класс C знает в ответ на какие события и при каких условиях должны вызываться методы класса B. Таким образом, класс C становится медиатором.
Итоги: Борьба со сложностью системы
Одной из важных проблем в программировании является наличие сложных систем из запутанных классов с большим количеством зависимостей (сильносвязанные системы). Управляя зависимостями, можно уменьшить связанность, упростить систему и достичь большей динамичности и гибкости.
Паттерн Observer уменьшает связанность за счёт обращения зависимостей. Он хорошо применим, когда есть несколько источников событий и много слушателей, которые добавляются динамически. Другим хорошим примером использования этого паттерна является реактивное программирование, когда изменение состояния одного объекта приводит к изменению состояния всех зависимых от него объектов и так далее.
Паттерн Mediator уменьшает связанность системы за счёт того, что все зависимости уходят в один класс медиатор, а все остальные классы становятся независимы и отвечают только за логику, которую они выполняют. Таким образом, добавление новых классов становится проще, но с каждым новым классом логика медиатора сильно усложняется. С течением времени, если медиатор продолжает бесконтрольно разрастаться, то его становится очень тяжело поддерживать.
Опасным подводным камнем при использовании паттернов Observer и Mediator является наличие циклических ссылок, когда события из одного класса, проходя по цепочки объектов, приводят к генерированию этого же события ещё раз. Эта проблема тяжело разрешима и заметно усложняет использование паттернов.
Таким образом, в разных обстоятельствах, управляя зависимостями, можно прийти к разным паттернам, иногда к их смеси, а иногда этот механизм окажется полезен без использования паттернов вовсе. Боритесь со сложностью и не плодите сущностей.
Mediator C# | Паттерн Посредник C#
Давайте рассмотрим паттерн проектирования Посредник C# — Mediator C#, для чего он нужен и какие проблемы он решает. Где можно применять данный шаблон, а где это будет излишним.
Идея паттерна Посредник (Mediator)
Паттерн (шаблон) проектирования — это продуманный способ построения исходного кода программы для решения часто возникающих в повседневном программировании проблем проектирования. Иными словами, это уже придуманное решения, для типичной задачи. При этом паттерн не готовое решение, а просто алгоритм действий, который должен привести к желаемому результату. Давайте рассмотрим один из наиболее часто используемых поведенческих паттернов — Посредник (Mediator).
Как я уже писал ранее, существует три вида паттернов проектирования:
Посредник (Mediator) — это поведенческий паттерн, который позволяет организовать работу множества слабо связанных объектов без непосредственного общения между ними. То есть, Посредник выступает промежуточным звеном между объектами, принимая и перенаправляя сообщения.
Архитектура паттерна проектирования Посредник
Логика работы Посредника
Рассмотрим основную логику работы паттерна Посредник. Давайте смоделируем процесс работы диспетчера полетов в аэропорту. Пилоты взлетающих или идущих на посадку самолетов в районе аэропорта общаются с диспетчером вместо непосредственного общения друг с другом. Диспетчер определяет, кто и в каком порядке будет садиться или взлетать. Данный механизм взаимодействия очень точно описывает логику работы паттерна Посредник.
Реализация паттерна Посредник (Mediator) на языке C#
Для начала создадим базовый интерфейс для самолета. В обычном случае я бы организовал это через интерфейс IAircraft, но так как это просто тестовый пример и мне не хочется дублировать код я организовал абстрактный класс, в котором реализовал всю логику, а конкретные реализации моделей самолетов не содержат практически никакой логики, а служат только для демонстрации.
Для удобства работы с кодом добавим перечисление, показывающее ткущее состояние самолета. Подробнее про работу с перечислениями можно прочитать в статье Отображение значения Enum в C# на русском.
Кроме того для работы аэродрома необходимы взлетно-посадочные полосы. Создадим для них класс.
Теперь самое важное. Диспетчер будет выступать посредником между самолетами и взлетно-посадочными полосами, выполняя поиск свободных полос и самолетов для взлета и посадки. То есть, не сам каждый самолет ищет свободную полосу, а он обращается к диспетчеру (посреднику) с запросом на посадку и ожидает разрешения.
Теперь нам остается только вызвать работу наших классов.
Получаем следующий результат работы приложения.
Исходный код приложения можно скачать из репозитория https://github.com/shwanoff/Mediator.
Таким образом, нам достаточно просто удалось разработать элементарную систему компьютерного моделирования работы аэропорта с использованием паттерна Посредник и асинхронного программирования.
Рекомендую также изучить статью Паттерн Адаптер (Adapter). А еще подписывайтесь на группу ВКонтакте, Telegram и YouTube-канал. Там еще больше полезного и интересного для программистов.
Паттерн CQRS: теория и практика в рамках ASP.Net Core 5
Скорость разработки и производительность программистов могут отличаться в зависимости от их уровня и используемых в проектах технологий. Для проектирования ПО нет стандартов и ГОСТов, только вы выбираете, как будете разрабатывать свою программу. Один из лучших способов повысить эффективность работы — применить шаблон проектирования CQRS.
Существует три вида паттерна CQRS: Regular, Progressive и Deluxe. В этой статье я расскажу о первом — классическом паттерне Regular CQRS, который мы используем в DD Planet в рамках разработки онлайн-сервиса «Выберу.ру». Progressive и Deluxe — более сложные архитектуры и влекут за собой использование обширного набора абстракций.
Я поделюсь опытом своей команды: как мы применили паттерн CQRS в бизнес-приложениях и беспроблемно внедрили его в существующие проекты, не переписывая тысячи строк кода.
Классический Onion
Чтобы было понятно, для чего нужен паттерн CQRS, сначала рассмотрим, как выглядит классическая архитектура приложения.
Классическая «луковая» архитектура состоит из нескольких слоев:
Доменный слой — наши сущности и классы.
Слой бизнес-логики, где происходит вся обработка доменной логики.
Слой приложения — логика самого приложения.
Внешние слои: слой UI, базы данных или тестов.
Это идеальная архитектура, которая существует множество лет, но она не создает ограничений для связанности компонентов.
Так произошло с нашим сайтом «Выберу.ру». Мы получили спагетти-код, в котором связанность была на очень высоком уровне. Новые разработчики приходили в шок, когда его видели. Самое страшное, что могло случиться — введение нового сотрудника в приложение. Объяснить, что и почему, казалось просто невозможным.
И мы подошли к моменту, когда перед нами встала важная задача устранить этот недостаток — инкапсулировать доменную логику в одном месте, уменьшить связанность и улучшить связность. Мы начали искать новые паттерны проектирования и остановились на CQRS.
Определение и задачи
CQRS (Command Query Responsibility Segregation)— это шаблон проектирования, который разделяет операции на две категории:
команды— изменяют состояние системы;
запросы— не изменяют состояние, только получают данные.
Подобное разделение может быть логическим и основываться на разных уровнях. Кроме того, оно может быть физическим и включать разные звенья (tiers), или уровни.
Обратите внимание, что это не паттерн кодирования, это паттерн проектирования. В разных компаниях этот паттерн используют по-разному, мы используем его в нашей команде «Выберу.ру», чтобы решить нескольких задач:
повысить скорость разработки нового функционала без ущерба для существующего;
снизить время подключения нового работника к проекту;
уменьшить количество багов;
упростить написание тестов;
повысить качество планирования разработки.
Благодаря CQRS мы получаем архитектуру, в которой все аккуратно разложено и понятно (меньше связанность, больше связности), человек может открыть код команды или запроса, увидеть все его зависимости, понять, что он делает, и продолжать работать над ним в рамках только этой команды/запроса, без копания в других частях программы.
Практика
Хочу поделиться, как мы используем шаблон CQRS на практике, и наглядно показать его плюсы.
Мы используем ASP.NET Core 5.0, поэтому примеры реализации паттерна будут в контексте этого фреймворка.
Помимо встроенных механизмов ASP.NET Core 5.0, нам понадобятся еще две библиотеки:
MediatR— небольшая библиотека, помогающая реализовать паттерн Mediator, который нам позволит производить обмен сообщениями между контроллером и запросами/командами без зависимостей.
Реализация REST API с помощью CQRS
Наши команды и запросы очень хорошо ложатся на REST API:
get — это всегда запросы;
post, put, delete — команды.
Добавление и настройка MediatR:
Чтобы добавить библиотеку в наш проект, выполним в консоли команду:
dotnet add package MediatR.Extensions.Microsoft.DependencyInjection
Далее зарегистрируем все компоненты нашей библиотеки в методе ConfigureServices класса Startup:
После мы напишем первую команду, пусть это будет команда добавления нового продукта в нашу базу данных. Сначала реализуем интерфейс команды, отнаследовавшись от встроенного в MediatR интерфейса IRequest
В конструкторе обработчика мы объявляем все зависимости, которые нужны нашей команде, и пишем бизнес-логику, в этом случае — сохранение сущности в БД.
Чтобы вызвать исполнение нашей команды, мы реализуем Action в нужном контроллере, пробросив интерфейс IMediator как зависимость. В качестве параметров экшена мы передаем нашу команду, чтобы механизм привязки ASP.Net Core смог привязать тело запроса к нашей команде. Теперь достаточно отправить команду через MediatR и вызвать обработчик нашей команды.
Благодаря возможностям MediatR мы можем делать самые разные декораторы команд/запросов, которые будут выполняться по принципу конвейера, по сути, тот же принцип реализуют Middlewares в ASP.Net Core при обработке запроса. Например, мы можем сделать более сложную валидацию для команд или добавить логирование выполнения команд.
Нам удалось упростить написание валидации команд с помощью FluentValidation.
Добавим FluentValidation в наш проект:
dotnet add package FluentValidation.AspNetCore
Создадим Pipeline для валидации:
И зарегистрируем его с помощью DI, добавим инициализацию всех валидаторов для FluentValidation.
Теперь напишем наш валидатор.
Благодаря возможностям C#, FluentValidation и MediatR нам удалось инкапсулировать логику нашей команды/запроса в рамках одного класса.
Это сильно упростило работу с API и решило все основные задачи.
На выходе получился красивый инкапсулированный код, понятный всем сотрудникам. Так, мы можем быстро ввести человека в процесс разработки, сократить затраты и время на его реализацию.
Текущие результаты можно посмотреть на GitHub.
Паттерн Mediator (посредник)
Назначение паттерна Mediator
Решаемая проблема
Мы хотим спроектировать систему с повторно используемыми компонентами, однако существующие связи между этими компонентами можно охарактеризовать феноменом «спагетти-кода».
Обсуждение паттерна Mediator
В Unix права доступа к системным ресурсам определяются тремя уровнями: владелец, группа и прочие. Группа представляет собой совокупность пользователей, обладающих некоторой функциональной принадлежностью. Каждый пользователь в системе может быть членом одной или нескольких групп, и каждая группа может иметь 0 или более пользователей, назначенных этой группе. Следующий рисунок показывает трех пользователей, являющихся членами всех трех групп.
Разбиение системы на множество объектов в общем случае повышает степень повторного использования, однако множество взаимосвязей между этими объектами, как правило, приводит к обратному эффекту. Чтобы этого не допустить, инкапсулируйте взаимодействия между объектами в объект-посредник. Действуя как центр связи, этот объект-посредник контролирует и координирует взаимодействие группы объектов. При этом объект-посредник делает взаимодействующие объекты слабо связанными, так как им больше не нужно хранить ссылки друг на друга – все взаимодействие идет через этого посредника. Расширить или изменить это взаимодействие можно через его подклассы.
Паттерн Mediator заменяет взаимодействие «все со всеми» взаимодействием «один со всеми».
Пример рационального использования паттерна Mediator – моделирование отношений между пользователями и группами операционной системы. Группа может иметь 0 или более пользователей, а пользователь может быть членом 0 или более групп. Паттерн Mediator предусматривает гибкий способ управления пользователями и группами.
Структура паттерна Mediator
UML-диаграмма классов паттерна Mediator
Коллеги (или взаимодействующие объекты) не связаны друг с другом. Каждый из них общается с посредником, который, в свою очередь, знает об остальных и управляет ими. Паттерн Mediator делает статус взаимодействия «все со всеми» «полностью объектным».
Пример паттерна Mediator
Паттерн Mediator определяет объект, управляющий набором взаимодействующих объектов. Слабая связанность достигается благодаря тому, что вместо непосредственного взаимодействия друг с другом коллеги общаются через объект-посредник. Башня управления полетами в аэропорту хорошо демонстрирует этот паттерн. Пилоты взлетающих или идущих на посадку самолетов в районе аэропорта общаются с башней вместо непосредственного общения друг с другом. Башня определяет, кто и в каком порядке будет садиться или взлетать. Важно отметить, что башня контролирует самолеты только в районе аэродрома, а не на протяжении всего полета.
Использование паттерна Mediator
Особенности паттерна Mediator
Реализация паттерна Mediator
Демонстрация паттерна Mediator
Степень повторного использования можно повысить через разбиение системы на множество объектов, однако при этом возникает множество взаимосвязей между этими объектами, которое приводит к обратному эффекту. Для исключения этой проблемы инкапсулируйте взаимодействие между объектами (коллективное поведение) в объект-посредник. Этот посредник будет управлять взаимодействием группы объектов.
FileSelectionDialog:: widgetChanged() инкапсулирует все коллективное поведение для диалогового окна (служит центром взаимодействия). Пользователь может выбрать «взаимодействие» с полем редактирования Filter, списком Directories, списком Files или полем редактирования Selection.
Результаты вывода программы:
Реализация паттерна Mediator: до и после
Объекты Node взаимодействуют друг с другом напрямую, требуется рекурсия, неудобное удаление узла, при этом первый узел удалить не возможно.
Результаты вывода программы:
После
«Посреднический» класс List упрощает все административные функции, рекурсия исключена.