Паттерн Mediator | Что это и зачем нужен

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

При прямой связи «каждый с каждым» количество зависимостей растёт как квадрат числа компонентов: изменения в одном классе часто заставляют править десятки других. Посредник помещает логику взаимодействия в одну точку:

class Mediator:
    """Интерфейс медиатора."""
    def notify(self, sender, event):
        raise NotImplementedError

class CourseMediator(Mediator):
    """Конкретный медиатор — координатор курсов и пользователей."""
    def __init__(self):
        self.users = []

    def register(self, user):
        self.users.append(user)
        user.mediator = self

    def notify(self, sender, course_name):
        # В простом варианте медиатор просто логирует сообщение
        print(f"[{sender}] выбрал курс: {course_name}")
        # Можно добавить дополнительную логику: фильтрация, отправка уведомлений и т.п.

class User:
    def __init__(self, name):
        self.name = name
        self.mediator = None

    def send_course(self, course_name):
        if not self.mediator:
            raise RuntimeError("User не зарегистрирован у медиатора")
        self.mediator.notify(self, course_name)

    def __str__(self):
        return self.name


m = CourseMediator()
u1 = User("Майкл"); u2 = User("Оля")
m.register(u1); m.register(u2)
u1.send_course("DSA")
u2.send_course("Software Development")

User не знает про других пользователей. Вся координация — в CourseMediator. Такой подход облегчает изменение логики (например, добавить рассылку уведомлений другим пользователям) без модификации User. Медиатор снижает связанность (Coupling) между компонентами и упрощает поддержку.


Плюсы

1️⃣ Централизация логики взаимодействия (проще править и тестировать).
2️⃣ Снижение связности между компонентами.
3️⃣ Легче добавлять новые стратегии взаимодействия, не меняя классы коллег.

Минусы

1️⃣ Риск «божественного объекта» (God Object): медиатор может накопить слишком много логики и стать сложным.
2️⃣ Централизация порождает узкое место — медиатор становится более сложным и менее прозрачным.

#основы
@zen_of_python

⚡ Прямой эфир с ментором по Python Сергеем Филичкиным

Забивайте слот в календаре:
📌 19 августа, 18:00 — Сергей Филичкин проведёт бесплатную открытую консультацию в «Коде найма».

Тему этого эфира помогли выбрать вы! Будем разбирать, «Как собирать офферы «про запас» и торговаться за лучшую цену». А вот более подробный план встречи:

🖇Как грамотно позиционировать себя на рынке, чтобы получить больше предложений.
🖇Психология успеха в переговорах: как уверенно говорить о деньгах.
🖇Тактика сбора офферов и ведения торгов.
🖇Лайфхаки по автоматизации поиска и переписки с рекрутерами.
🖇Блок Q&A с разбором ваших ситуаций.

💬 Оставляйте свои вопросы Сергею под этим постом — чтобы наш ментор дал развернутые и действительно рабочие советы!

✅Python-карьера в 2025 без воды: деньги, офферы, переговоры. Подписывайся.

ИП Филичкин Сергей Андреевич ИНН 183401586208, erid: 2W5zFJydiRE