Паттерны проектирования, которые должен знать каждый разработчик

Паттерны проектирования, которые должен знать каждый разработчик

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

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

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

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

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

Зачем разработчику знать паттерны?

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

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

Паттерны особенно полезны, когда:

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

Основные группы паттернов

Порождающие паттерны управляют созданием объектов. К ним относятся Factory Method, Builder и Singleton.

Структурные паттерны помогают объединять классы и объекты. Среди них можно выделить Adapter, Decorator и Facade.

Поведенческие паттерны определяют взаимодействие между объектами. К этой группе относятся Strategy, Observer, Command и State.

Factory Method: создание объектов

Factory Method применяется, когда программа должна создавать объекты разных классов, но основной код не должен зависеть от конкретной реализации.

Например, приложение может отправлять уведомления через электронную почту или SMS. Вместо создания объектов непосредственно в бизнес-логике эту задачу можно передать фабрике.

interface Notification { void send(String message); } class EmailNotification implements Notification { public void send(String message) { System.out.println(«Email: » + message); } } class SmsNotification implements Notification { public void send(String message) { System.out.println(«SMS: » + message); } } class NotificationFactory { public static Notification create(String type) { if (type.equalsIgnoreCase(«email»)) { return new EmailNotification(); } if (type.equalsIgnoreCase(«sms»)) { return new SmsNotification(); } throw new IllegalArgumentException(«Unknown type»); } }

Остальная часть программы работает с интерфейсом Notification и не зависит от конкретного класса. Это упрощает добавление новых способов отправки сообщений.

Builder: создание сложных объектов

Builder полезен, когда объект содержит много обязательных и необязательных параметров. Вместо длинного конструктора объект создаётся пошагово.

User user = new User.Builder(«Alex») .email(«[email protected]») .age(28) .phone(«+123456789») .build();

Такой код легче читать, поскольку видно назначение каждого значения. Внутри метода build() также можно проверять корректность данных.

Builder часто используется для создания конфигураций, HTTP-запросов, моделей и объектов с большим количеством настроек.

Singleton: один экземпляр класса

Singleton гарантирует, что в приложении существует только один экземпляр определённого класса. Обычно он используется для конфигурации, журналирования или общего кеша.

public class AppConfig { private static AppConfig instance; private AppConfig() { } public static AppConfig getInstance() { if (instance == null) { instance = new AppConfig(); } return instance; } }

Закрытый конструктор запрещает создавать объект извне, а метод getInstance() возвращает существующий экземпляр или создаёт его при первом обращении.

Использовать Singleton следует осторожно. Он создаёт глобальное состояние, усложняет тестирование и требует дополнительной синхронизации в многопоточных приложениях.

Adapter: совместимость интерфейсов

Adapter позволяет использовать сторонний класс с неподходящим интерфейсом. Адаптер принимает вызовы в формате приложения и преобразует их в формат внешнего компонента.

interface PaymentService { void pay(double amount); } class ExternalPaymentApi { public void makePayment(double value) { System.out.println(«Paid: » + value); } } class PaymentAdapter implements PaymentService { private final ExternalPaymentApi api; public PaymentAdapter(ExternalPaymentApi api) { this.api = api; } public void pay(double amount) { api.makePayment(amount); } }

Теперь программа работает с привычным интерфейсом PaymentService, а особенности внешнего API остаются внутри адаптера.

Паттерн часто применяется при подключении платёжных систем, сторонних библиотек, старого кода и внешних сервисов.

Decorator: расширение поведения

Decorator позволяет добавлять объекту новое поведение без изменения исходного класса и создания большого количества наследников.

interface MessageSender { void send(String message); } class BasicSender implements MessageSender { public void send(String message) { System.out.println(message); } } class LoggingDecorator implements MessageSender { private final MessageSender sender; public LoggingDecorator(MessageSender sender) { this.sender = sender; } public void send(String message) { System.out.println(«Log: sending message»); sender.send(message); } }

Декораторы можно комбинировать. Например, к отправителю сообщений можно последовательно добавить журналирование, шифрование и проверку данных.

Facade: простой интерфейс сложной системы

Facade предоставляет единый и понятный интерфейс для работы с несколькими внутренними компонентами.

Например, оформление заказа может включать резервирование товара, оплату, создание доставки и отправку уведомления. Клиентскому коду необязательно самостоятельно управлять каждым этапом.

class OrderFacade { private final InventoryService inventory; private final PaymentService payment; private final DeliveryService delivery; public void createOrder(Product product) { inventory.reserve(product); payment.pay(product.getPrice()); delivery.createDelivery(product); } }

Фасад уменьшает количество зависимостей и скрывает сложную последовательность внутренних операций.

Strategy: замена алгоритмов

Strategy выносит взаимозаменяемые алгоритмы в отдельные классы. Основной объект работает через общий интерфейс и может менять стратегию во время выполнения программы.

interface DeliveryStrategy { double calculate(double orderPrice); } class StandardDelivery implements DeliveryStrategy { public double calculate(double orderPrice) { return 10; } } class ExpressDelivery implements DeliveryStrategy { public double calculate(double orderPrice) { return 25; } } class Order { private DeliveryStrategy strategy; public void setStrategy(DeliveryStrategy strategy) { this.strategy = strategy; } public double getDeliveryPrice(double orderPrice) { return strategy.calculate(orderPrice); } }

Каждый алгоритм хранится отдельно, легко тестируется и заменяется без изменения класса заказа.

Strategy используется для расчёта скидок, доставки, выбора способа оплаты, сортировки, валидации и обработки данных.

Observer: система подписок

Observer применяется, когда изменение одного объекта должно автоматически уведомлять несколько других объектов.

interface Subscriber { void update(String news); } class NewsPublisher { private final List subscribers = new ArrayList(); public void subscribe(Subscriber subscriber) { subscribers.add(subscriber); } public void publish(String news) { for (Subscriber subscriber : subscribers) { subscriber.update(news); } } }

Издатель не знает деталей работы подписчиков. Он только вызывает общий метод уведомления.

Observer встречается в графических интерфейсах, системах событий, уведомлениях, реактивном программировании и архитектуре MVC.

Command: действие как объект

Command превращает действие в самостоятельный объект. Такие команды можно сохранять, помещать в очередь, повторять или отменять.

interface Command { void execute(); void undo(); } class TurnOnLightCommand implements Command { private final Light light; public TurnOnLightCommand(Light light) { this.light = light; } public void execute() { light.turnOn(); } public void undo() { light.turnOff(); } }

Паттерн используется в текстовых редакторах, пользовательских интерфейсах, очередях задач и системах с отменой действий.

State: поведение в зависимости от состояния

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

Например, заказ может быть создан, оплачен, отправлен или отменён. В каждом состоянии доступны разные действия. Отправленный заказ нельзя оплатить повторно, а отменённый нельзя передать в доставку.

State разделяет эти правила и помогает избежать большого количества вложенных конструкций if и switch.

Repository и Dependency Injection

Repository отделяет бизнес-логику от способа хранения данных. Основной код работает через интерфейс и не зависит напрямую от SQL-запросов или конкретной базы данных.

interface UserRepository { User findById(long id); void save(User user); void delete(long id); }

Dependency Injection предполагает, что объект не создаёт зависимости самостоятельно, а получает их извне.

class UserService { private final UserRepository repository; public UserService(UserRepository repository) { this.repository = repository; } }

Такой подход уменьшает связанность компонентов и упрощает тестирование, поскольку реальную зависимость можно заменить тестовой реализацией.

Какие паттерны изучать в первую очередь?

Новичку необязательно сразу запоминать все существующие паттерны. Для начала достаточно изучить несколько наиболее распространённых решений.

Factory Method и Builder помогают создавать объекты.Adapter и Facade упрощают интеграцию компонентов.Decorator добавляет новое поведение.Strategy позволяет заменять алгоритмы.Observer используется для событий и подписок.Command представляет действия в виде объектов.Repository и Dependency Injection уменьшают зависимость бизнес-логики от инфраструктуры.

Ошибки при использовании паттернов

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

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

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

Игнорирование особенностей языка. Один и тот же паттерн по-разному реализуется в Java, Python, JavaScript, C#, Go или Rust. Иногда вместо нескольких классов достаточно функции или замыкания.

Заключение

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

Каждому разработчику полезно понимать Factory Method, Builder, Adapter, Decorator, Facade, Strategy, Observer и Command. В современных проектах также часто используются Repository и Dependency Injection.

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

Источник