Паттерны проектирования в программировании

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

Паттерны проектирования — это проверенные решения для таких повторяющихся ситуаций. Готового кода они не дают, но подсказывают, как организовать структуру программы, чтобы она была понятной и надёжной.

Сегодня рассмотрим, какие бывают паттерны и как их применять.

Что такое паттерны проектирования в программировании

Паттерн проектирования — это типовое решение распространённой архитектурной задачи. В чём отличие от библиотек и фреймворков? Это не готовая функция или метод, которые нужно просто вставить. Паттерн — это способ организации программы.

Например, можно придумать гибкий способ создания заказов в интернет-магазине или подключения платёжных систем. Применяя паттерн, можно удобно организовать работу и потом легко менять бизнес-логику.

Такой шаблон программирования не говорит строго: «напиши такую строку кода», а руководит организацией взаимодействия частей системы. Вместо синтаксиса паттерны устанавливают архитектуру.    

Например, паттерн может помочь уменьшить жёсткую зависимость между сервисами и сделать систему более гибкой, но при этом устойчивой.

Зачем нужны паттерны в программировании: 4 ключевые выгоды

Шаблоны программирования помогают решать реальные проблемы разработки: сложность, масштабируемость, поддерживаемость.

Ускорение разработки и читаемость кода

Разработчик со знанием паттернов видит проблему и сразу понимает, какое решение обычно применяется. Например, для уведомления нескольких частей системы об изменении данных понадобится паттерн Observer. В итоге работа становится предсказуемее и быстрее.

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

Универсальный язык для команды разработчиков

Паттерны — это способ общения между программистами. Можно сказать: «Давайте сделаем фабрику» — и остальные сразу поймут идею. Это важно в больших проектах, где участвуют несколько человек. А ещё снижается риск недопонимания и архитектурных конфликтов.

Предотвращение скрытых проблем и ошибок

Паттерны помогают избежать типичных архитектурных ловушек, например, слишком сильной зависимости между компонентами. Если один сервис напрямую зависит от реализации другого, при изменении вся система может сломаться. Паттерн помогает сделать фрагменты программы более изолированными друг от друга.

Учебный пример: фронтенд напрямую вызывает методы базы данных через общий модуль. Если изменить структуру БД, половина приложения может перестать работать. А вот если правильно пользоваться паттернами, архитектура уменьшает такие риски. Это способ заранее подумать о будущем.

Опыт поколений в вашем проекте

Паттерны описаны в книге Design Patterns: Elements of Reusable Object-Oriented Software. Авторы собрали типовые решения, которые использовались в десятках реальных проектов. Получается, что с паттернами вы применяете проверенный опыт множества разработчиков. Это сравнимо с использованием инженерных норм в строительстве.

Классификация паттернов

Паттерны обычно делят на три большие группы: порождающие, структурные и поведенческие. Каждая группа решает свой тип задач.

Порождающие паттерны (Creational)

Отвечают за то, как создаются объекты, упрощают процесс создания, убирают дублирование кода.

На практике создание объектов может быть сложным и встречаться в нескольких местах кода. Это нехорошо, потому что может вызвать дублирование кода, ошибки и сложности в изменениях. Порождающие паттерны помогают управлять процессом создания, чтобы потом объектами было проще управлять.

Структурные паттерны (Structural)

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

В реальной ситуации это может выглядеть так: старый API возвращает данные в одном формате, а новый сервис ожидает другой. Например, у методов могут быть разные имена или разные форматы данных. Тут может помочь паттерн Adapter, который создаёт адаптер-переходник: снаружи код выглядит так, как ожидает один интерфейс, а внутри переводит вызовы и данные в формат чужой библиотеки. В итоге вы не переписываете старый (или чужой) модуль и не ломаете свой код по всему проекту.

Поведенческие паттерны (Behavioral)

Описывают, как объекты обмениваются данными и управляют поведением. 

Например, паттерн Observer позволяет объектам подписываться на события и автоматически получать уведомления. Это похоже на систему уведомлений: пользователь изменил настройки, и интерфейс сразу обновился. Такое поведение кажется очевидным, но без этого пришлось бы вручную обновлять каждую часть системы.

Популярные паттерны с примерами

Вот три самых известных паттерна.

Singleton (Одиночка): гарантия одного экземпляра

Применяется, когда в приложении должен быть один общий объект: логгер, конфиг, пул подключений к БД.

Что в примере: создаём одну базу данных на всю программу. Сначала посмотрим код, а потом разберём принцип работы.

# создаём класс, который хотим сделать «одиночкой»
class Database:
   # заводим переменную класса, где будем хранить единственный экземпляр
   _instance = None

   # переопределяем создание объекта (до __init__)
   def __new__(cls):
       # если экземпляра ещё нет — создаём
       if cls._instance is None:
           # вызываем базовую реализацию __new__, чтобы реально выделить объект
           cls._instance = super().__new__(cls)
       # возвращаем уже существующий (или только что созданный) экземпляр
       return cls._instance

# создаём первый объект
db1 = Database()
# создаём второй объект, но на самом деле получим тот же самый
db2 = Database()

# проверяем, что это один и тот же объект в памяти
print(db1 is db2)

Сначала мы объявляем класс Database и кладём внутрь переменную _instance, где будем хранить единственный объект. Потом проверяем каждый момент создания объекта через __new__: когда разработчик пишет Database(), Питон пытается создать новый объект, и именно в этот момент наш код проверяет — а нет ли такого объекта уже?

Если объекта нет, программа создаёт его один раз и сохраняет в _instance. Если объект уже создан, мы не создаём новый, а просто возвращаем сохранённый. Поэтому сколько бы раз вы ни вызывали Database(), код будет выдавать один и тот же объект.

Польза проста: вместо того чтобы случайно создать 10 объектов, вы гарантируете один источник правды.

Если запустить этот код, мы увидим, что это действительно один и тот же объект:

True

Factory Method (Фабричный метод): гибкое создание объектов

Выносит создание объектов в отдельный метод. Сначала пишем основной шаблон для всех объектов, потом прописываем каждый вид-ответвление отдельно.

Сначала код:

# задаём общий интерфейс отчёта
class Report:
    # описываем метод, который должен быть у всех отчётов
    def render(self) -> str:
        # говорим: реализация обязана быть в потомках
        raise NotImplementedError

# делаем конкретный отчёт в PDF
class PDFReport(Report):
    # реализуем метод для pdf
    def render(self) -> str:
        # возвращаем условное содержимое pdf
        return "PDF: ..."

# делаем конкретный отчёт в HTML
class HTMLReport(Report):
    # реализуем метод для html
    def render(self) -> str:
        # возвращаем условное содержимое html
        return "<html>...</html>"

# создаём фабрику, которая решает, какой класс создать
class ReportFactory:
    # объявляем статический метод (вызывается без создания объекта фабрики)
    @staticmethod
    def create(report_type: str) -> Report:
        # если нужен pdf — создаём PDFReport
        if report_type == "pdf":
            return PDFReport()
        # если нужен html — создаём HTMLReport
        if report_type == "html":
            return HTMLReport()
        # если тип неизвестен — кидаем понятную ошибку
        raise ValueError(f"unknown report_type: {report_type}")

# просим фабрику создать нужный объект
report = ReportFactory.create("html")
# используем объект единообразно, не думая о его конкретном классе
print(report.render())

А вот как это работает.

Сначала мы описываем общий договор. Любой отчёт умеет выдать результат — это прописано в команде render(). Затем создаём конкретные реализации: PDFReport и HTMLReport — оба умеют выполнять render(), но возвращают результат в разных форматах. В нашем коде нет полной реализации генерации отчётов, потому что это просто учебный пример. А в реальной программе получались бы документы форматов PDF или HTML.

Далее появляется фабрика ReportFactory: здесь мы собираем решение «какой именно объект создавать». Если передаём строку типа "html" — фабрика возвращает нужный класс. При этом код не привязан к конкретным классам: он работает с отчётом одинаково, просто вызывая render().

В реальном приложении это помогает, если есть несколько вариантов одного действия: разные форматы отчётов, способы оплаты, хранилища, клиенты API. С таким решением не нужно повторять условия if/else по всему проекту, а можно просто собрать всё в одном понятном месте, где выбирается реализация.

Observer (Наблюдатель): механизм событий и подписок

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

Смотрим пример:

# описываем наблюдателя
# у наблюдателя должен быть метод update
class Observer:
   # задаём контракт обновления
   def update(self, data) -> None:
       # говорим, что реализация должна быть в потомках
       raise NotImplementedError

# описываем субъект, источник событий
class Subject:
   # инициализируем субъект
   def __init__(self):
       # создаём список подписчиков
       self._observers = []

   # добавляем подписчика
   def subscribe(self, observer: Observer) -> None:
       # кладём подписчика в список
       self._observers.append(observer)

   # удаляем подписчика
   def unsubscribe(self, observer: Observer) -> None:
       # убираем подписчика из списка
       self._observers.remove(observer)

   # уведомляем всех подписчиков
   def notify(self, data) -> None:
       # проходим по всем подписчикам
       for observer in self._observers:
           # вызываем у каждого update и передаём данные
           observer.update(data)

# делаем конкретного подписчика, который печатает события
class PrintObserver(Observer):
   # реализуем обновление
   def update(self, data) -> None:
       # выводим полученные данные
       print(f"got event: {data}")

# создаём источник событий
subject = Subject()
# создаём подписчика
printer = PrintObserver()
# подписываемся на события
subject.subscribe(printer)
# отправляем событие всем подписчикам
subject.notify({"status": "ok"})

Разберём, как что работает.

Сначала создаём источник событий Subject и внутри него храним список подписчиков. Потом создаём подписчика — в нашем примере это PrintObserver. Подписываем PrintObserver на события — для этого используется subscribe(). Теперь, когда в системе что-то происходит, источник вызывает функцию notify(data) и автоматически выдаёт событие всем подписчикам: у каждого вызывается update(data).

То есть логика такая: источник не знает, что вы будете делать с событием, он просто сообщает о том, что событие произошло. А подписчики решают, как реагировать: один печатает сообщение, другой обновляет интерфейс, третий отправляет уведомление.

В реальном коде это удобно для интерфейса, системы уведомлений, реакции на изменения данных, а ещё — для событий в микросервисах. Главный плюс в том, что можно добавлять новые реакции микросервисов, не переписывая источник событий — достаточно подключить нового подписчика, и всё.

Паттерны и шаблоны разработки: как не навредить проекту

Паттерны разработки — это инструмент, но неправильное применение может усложнить систему. 

Главное правило: паттерн — не догма, а инструмент

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

Типичные ошибки: избыточное усложнение (over-engineering)

Если добавлять фабрики, абстрактные классы и интерфейсы там, где можно обойтись двумя функциями, код станет сложно читать и поддерживать.

Например, маленький pet-проект превращается в мини-корпоративную систему с десятками файлов, и скорость разработки падает.

Как правильно выбирать паттерн для своей задачи

Сначала нужно понять проблему. Есть ли сильная связанность? Часто ли меняется логика создания объектов? Нужны ли события? Только после этого можно выбирать паттерн. Если вы не можете чётко объяснить, зачем он нужен, — скорее всего, не нужен.

Если интересно изучить паттерны поподробнее, узнавать их и научиться выбирать, попробуйте сайт refactoring.guru. Там есть подробное описание с иллюстрациями, примерами и много другого интересного: