Какие паттерны проектирования используете чаще всего в Python-коде?

На собеседовании по Python от middle обычно ждут не перечисления всех 23 паттернов GoF, а понимания, как решать типичные задачи архитектуры в живом коде.

Фабрики и фабричные функции (Factory, Factory Method)

В Python часто используют простые фабричные функции или классы‑фабрики:

• скрыть детали конфигурации объекта (клиент к БД, HTTP‑клиент, репозиторий);

• выбирать конкретную реализацию по настройкам/окружению (mock vs real, разные драйверы);

• интегрировать с DI‑контейнерами.

Стратегия (Strategy)

Strategy удобно использовать там, где есть несколько алгоритмов под один интерфейс:

• разные политики ретраев;

• варианты расчёта цены/скидок;

• разные провайдеры уведомлений (email, SMS, push).

В Python стратегия часто выглядит как набор классов с общим интерфейсом или просто набор функций/корутин, хранящихся в словаре по ключу (mapping[key](...)), плюс Protocol для типобезопасности.

Адаптер и Фасад (Adapter, Facade)

При работе с внешними сервисами (платёжки, CRM, склад) удобно:

• делать Adapter, который приводит неудобный/шумный внешний API к нашему доменному интерфейсу;

• строить поверх нескольких низкоуровневых клиентов Facade — один высокоуровневый сервис, который решает задачу бизнеса и прячет детали интеграций.

Это даёт более чистый доменный код и упрощает тестирование (можно подменять фасад или адаптер).

Repository и Service (слой домена / слой приложений)

Частый практический паттерн в Python‑backend — Repository + Service:

• Repository инкапсулирует доступ к данным (БД, кеш, внешние API), возвращая доменные объекты;

• Service реализует бизнес‑логику, опираясь на репозитории и другие сервисы, не зная деталей БД.

Это помогает держать доменную логику независимой от инфраструктуры, облегчает миграции между БД и тестирование.

Декоратор (в том числе синтаксический @decorator)

Декоратор в Python естественен благодаря синтаксису @name:

• логирование и трассировка вызовов;

• кеширование (@lru_cache, свои декораторы кеша);

• контроль доступа, ретраи, метрические счётчики;

• единая обработка ошибок.

Важно уметь писать декораторы и понимать, как они влияют на сигнатуры функций (использование functools.wraps и typing).

Observer / Pub‑Sub, CQRS, Event‑driven

В более сложных системах часто всплывают event‑подходы:

• Observer / Pub‑Sub: внутренний event‑bus или брокер сообщений (Kafka, RabbitMQ) со слушателями;

• CQRS и разделение команд/запросов в приложениях с насыщенным доменом.

Реализуются они чаще на уровне инфраструктуры (брокеры, handlers), но важно понимать мотив: развязать отправителя и получателя, масштабировать обработку, упростить расширение поведения.

Хорошая формулировка для ответа

В реальном Python‑коде я чаще использую фабрики и strategy для выбора поведения, adapter/facade для интеграций с внешними системами, Repository/Service для разделения домена и инфраструктуры и декораторы для кросс‑срезочных задач (логирование, кеш, ретраи, права доступа). При нужной сложности системы добавляются event‑подходы (Observer/pub‑sub) и элементы CQRS. Чистые классовые паттерны GoF я подстраиваю под идиоматику Python (функции первого класса, декораторы, dataclasses, typing).