Между тем у этой задачи есть три принципиально разных уровня решения, и выбор уровня определяется не языком, а требованиями к задержке. Разбираем все три: блокирующую очередь на Java, каналы и горутины в Go и очередь без блокировок на Rust.

Producer-Consumer — это схема, в которой производители и потребители работают независимо, обмениваясь данными через общий буфер конечной ёмкости. Ёмкость здесь работает главным механизмом защиты: именно она не даёт быстрым производителям завалить медленных потребителей.

Ручная координация через wait() и notifyAll() в блоках синхронизации даёт гонки и ложные пробуждения, а активное ожидание в цикле впустую жжёт процессор.

Готовая блокирующая очередь решает задачу целиком: при переполнении она сама останавливает производителя, обеспечивая обратное давление вместо переполнения памяти.

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

Три гарантии прогресса различаются строго: obstruction-free требует отсутствия помех, lock-free гарантирует прогресс системы в целом, wait-free — завершение каждой операции за ограниченное число шагов.

Отсутствие блокировок и использование атомарных операций сами по себе не дают wait-free: цикл повторных попыток без верхней границы — это lock-free, как бы его ни называли в описании библиотеки.

Уровень первый: блокирующая очередь Producer-Consumer

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

• Писать собственную логику блокировок через wait() и notifyAll() внутри синхронизированных блоков. Это приносит тонкие гонки и баги ложного пробуждения, когда поток просыпается без всякого уведомления.
• Крутить активное ожидание в бесконечном цикле поверх коллекции, не рассчитанной на многопоточность. Процессор загружен постоянной проверкой размера очереди, а корректности всё равно нет.
• Не предусмотреть обратного давления. Когда производители быстрее потребителей, буфер растёт, пока приложение не упрётся в нехватку памяти.

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

В Java всё это уже реализовано в стандартной библиотеке:

Вся координация потоков спрятана внутри реализации очереди, и явных блокировок в коде не остаётся вовсе. Метод put останавливает производителя при переполнении, и это и есть обратное давление, ради которого затевалась ограниченная ёмкость.

Уровень второй: передача сообщений вместо общей памяти

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

Ключевое слово go перед вызовом запускает функцию конкурентно. Правда, у примера выше есть подвох: когда main завершается, программа выходит целиком, и горутина может не успеть отработать. Дожидаться её нужно явно:

Где здесь, собственно, очередь

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

Поведение совпадает с блокирующей очередью один в один: отправка встаёт при переполнении, приём встаёт на пустом канале. Разница в акценте. В Java вы защищаете общий буфер, в Go передаёте значение из одной горутины в другую, и владение данными переходит вместе с ним.

Почему это не просто потоки с коротким именем

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

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

Уровень третий: очередь без блокировок

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

Три гарантии прогресса

Obstruction-free. Операция завершится, если в какой-то момент ей дадут поработать без помех со стороны других потоков. При непрерывных помехах прогресс не гарантирован вообще. Самая слабая из трёх гарантий.

Lock-free. Гарантирует прогресс системы в целом: даже если один поток застрял, какой-то другой обязательно завершит свою операцию. Отдельный поток при этом может голодать сколь угодно долго, но система не встаёт целиком.

Wait-free. Каждая операция завершается за ограниченное число шагов независимо от того, что делают остальные потоки. Ключевая формулировка здесь именно «ограниченное число шагов», а не «обычно быстро», «не использует блокировок» или «работает на атомарных операциях». Это формальное свойство, а не характеристика скорости.

Два неравенства, которые стоит запомнить:
Отсутствие блокировок не равно wait-free. Использование атомарных операций тоже не равно wait-free.

Почему мьютекса недостаточно

Очередь, обёрнутая в мьютекс, — это совершенно корректный многопоточный код на Rust. Но wait-free она не является: поток, захвативший блокировку, может быть снят с процессора планировщиком, и все остальные будут ждать его возвращения неограниченно долго. Для большинства задач это приемлемо, для систем с жёсткими требованиями по задержке уже нет.

Атомарность и упорядочивание — разные вещи

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

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

Кольцевой буфер и номера последовательности

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

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

Тип UnsafeCell здесь означает ровно то, что написано на упаковке: обращаться к значению можно только из блока unsafe, компилятор проверку прекращает, и инвариант «в конкретный момент со слотом работает один поток» держится на номере последовательности, а не на системе типов.

Тип MaybeUninit здесь не для красоты: при ёмкости в 1024 элемента нужны 1024 места под значения, а не 1024 сконструированных объекта. Производитель получает уникальную позицию одним атомарным инкрементом, и никакого соревнования за неё не возникает:

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

Где заканчивается честность в названиях

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

Операция обычно завершается быстро, но верхней границы на число неудачных попыток здесь нет, а именно она и определяет wait-free. И да, ровно такой цикл вы только что видели в нашей собственной очереди: строго говоря, на этом шаге она тоже lock-free, а не wait-free, и автор исходного разбора это прямо оговаривает. Строгая реализация требует ограниченной стратегии резервирования или механизма помощи: когда поток B встречает незавершённую операцию потока A, он не ждёт возвращения A, а доводит его операцию до конца сам. Так прогресс перестаёт зависеть от того, что планировщик сделал с конкретным потоком.

Какой уровень выбрать

Правило простое и почти всегда работает от обратного.

• Блокирующая очередь из стандартной библиотеки закрывает подавляющее большинство задач. Начинайте с неё и не пишите координацию потоков вручную.
• Модель с передачей сообщений выигрывает, когда конкурентных задач много, а связи между ними хочется описать явно, а не через набор общих структур под блокировками.
• Алгоритмы без блокировок берутся, когда есть измеренное требование к задержке, которое блокировка нарушает: не «хочется быстрее», а конкретная цифра в бюджете. И в продакшене их берут готовыми из библиотек вроде crossbeam, а разбирают по косточкам ради понимания механики.

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

Что забрать с собой

Задача Producer-Consumer решается на трёх уровнях, и уровень выбирается требованиями, а не вкусом. Ограниченный буфер с обратным давлением закрывает большинство случаев. Передача сообщений упрощает структуру, когда конкурентных задач становится много. Алгоритмы без блокировок нужны там, где блокировка нарушает измеренный бюджет задержки, и тогда важно понимать, какую именно гарантию вы покупаете.

Материалы разбора: задача о ресторанной кухне на Java, введение в горутины и модель конкурентности Go и построение wait-free очереди на Rust.

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

В нашей системе две базы данных:

- Остатки по счетам - текущий остаток по каждому счёту

- Остатки по клиентам - агрегированный баланс клиента по всем его счетам.

При каждом изменении остатка по счёту нужно обновить Остатки по счетам и уведомить Остатки по клиентам через Kafka. Логика простая. Но в какой-то момент клиент звонит в поддержку: его баланс в приложении не совпадает с реальным. Вы смотрите в обе базы — данные разошлись. Когда именно это произошло — непонятно.

Причина почти всегда одна и та же:

Транзакция закоммичена, событие не ушло. Базы разошлись. Никто не узнал.

Почему очевидные решения не работают

Первая реакция разработчика — обернуть отправку в try-catch и повторить при ошибке:

Не работает: транзакция уже закоммичена до отправки. При сбое Kafka данные обновлены, событие потеряно. Retry помогает только если Kafka временно недоступна — но не при падении самого сервиса между коммитом и отправкой.

Вторая идея — отправить событие до коммита:

Тоже не работает: если коммит упадёт, Kafka уже получила событие об изменении, которого нет в базе. Данные снова разошлись, но в другую сторону.

Третья идея — двухфазный коммит (2PC). Это протокол, который координирует атомарный коммит сразу в нескольких системах. Звучит как решение, но на практике Kafka его не поддерживает в классическом смысле, а реализации 2PC с брокерами сообщений крайне сложны в эксплуатации и плохо переносят сбои координатора.

Все три пути упираются в одну проблему: **невозможно атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka** — это две разные системы без общего менеджера транзакций.

Принцип решения

Раз нельзя сделать две операции атомарными, нужно свести их к одной. Именно это делает паттерн **Transactional Outbox**.

Вместо того чтобы отправлять событие в Kafka напрямую, мы записываем его в таблицу `outbox` — в той же базе, в той же транзакции, что и изменение остатка. Одна транзакция, одна база, полная атомарность за счёт ACID.

Доставкой события из `outbox` в Kafka занимается отдельный процесс — уже без транзакционных рисков, с возможностью повторных попыток.

Это и есть весь паттерн. Дальше — вопрос реализации.

Два способа реализации

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

Способ 1: Polling Relay

Фоновый воркер периодически опрашивает 'outbox' и отправляет неотправленные события в Kafka.

Структура таблицы outbox:

Бизнес-транзакция:

Relay-процесс:

При нескольких экземплярах ретранслятора важно, чтобы одно событие забирал только один из них. Используем `FOR UPDATE SKIP LOCKED`:

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

Способ 2: CDC через Debezium

CDC (Change Data Capture) — подход, при котором события читаются не опросом таблицы, а напрямую из журнала транзакций базы данных (WAL в PostgreSQL). [Debezium](https://debezium.io/) подключается к PostgreSQL как репликационный слот и стримит каждое изменение в `outbox` в Kafka в реальном времени.

Relay-процесс при этом не нужен вообще.

Бизнес-транзакция остаётся той же — пишем в `accounts` и `outbox` атомарно. Debezium сам следит за WAL и публикует новые записи в Kafka с минимальной задержкой.

Когда выбирать: нужна задержка доставки в миллисекунды, команда готова к Debezium + Kafka Connect в инфраструктуре.

Что выбрать для синхронизации остатков

Для большинства задач с остатками по счетам polling relay достаточен. CDC имеет смысл, если бизнес требует обновления клиентского баланса быстрее чем за секунду.

Получатель: защита от дублей

Оба способа доставляют события как минимум один раз — при повторных попытках одно событие может прийти дважды. На стороне Остатков по клиентам нужна защита.

Самый надёжный способ — inbox-таблица с уникальным constraint:

>Почему не `existsById` перед вставкой? При параллельной обработке два консюмера могут одновременно получить `false` и оба начать обработку. Уникальный constraint на уровне БД закрывает эту гонку.

Что сломается при небрежной реализации

Relay внутри API-сервиса. Если ретранслятор живёт в том же процессе, что и API, горизонтальное масштабирование до 10–30 реплик создаёт столько же потоков, опрашивающих `outbox`. База тратит CPU не на запросы, а на управление блокировками. Relay — отдельный деплоймент, который масштабируется по объёму событий, а не по HTTP-трафику.

Таблица outbox незаметно растёт. Без очистки запросы замедляются, индексы раздуваются. Настройте автоматическую очистку:

Отсутствие мониторинга outbox. Outbox — скрытая очередь внутри базы. Если relay начнёт отставать, вы узнаете об этом от клиентов, а не от алертов. Следите за количеством и возрастом необработанных событий — это главные сигналы проблемы.

Итог

Проблема потери событий при синхронизации баз — не баг конкретной реализации. Это фундаментальное ограничение: нельзя атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka.

Transactional Outbox обходит это ограничение, сводя две операции к одной: событие пишется в `outbox` в той же транзакции, что и основные данные. Дальше — дело техники: polling relay, если нужна простота, CDC, если нужна скорость.

Остатки по счетам и клиентам будут согласованы — даже если между сервисами что-то пойдёт не так.

REST API — это веб-сервис, удовлетворяющий шести архитектурным ограничениям, выведенным Роем Филдингом в докторской диссертации «Architectural Styles and the Design of Network-based Software Architectures» (UC Irvine, 2000 год). Начав с «нулевого стиля» — пустого набора без ограничений — Филдинг добавлял каждое из них последовательно, анализируя порождаемые ими свойства распределённых гипермедиа-систем (систем, где переходы между состояниями описаны прямо в ответах сервера). Результат получил название «Передача репрезентативного состояния» (Representational State Transfer).

Индустрия взяла название и проигнорировала большинство ограничений. «REST» теперь означает «любой API, который отправляет JSON по HTTP». Если вы строите публичный API или API для команд за пределами вашей организации — пропущенные ограничения начинают стоить денег.

REST — это шесть архитектурных ограничений, сформулированных Роем Филдингом в 2000 году, а не «любой JSON-over-HTTP API».

Большинство API выполняют лишь 2–3 ограничения из шести: клиент-сервер, stateless и частично слоистую систему.

Самое игнорируемое ограничение — HATEOAS: сервер передаёт клиенту список доступных действий прямо в ответе.

HATEOAS решает три дорогостоящие проблемы: пагинацию, версионирование API и обнаруживаемость ресурсов.

Для небольшой команды с одним потребителем пропуск HATEOAS оправдан. Для публичного API — нет.

Шесть ограничений REST API: разбор по порядку

Ограничение 1: Клиент-сервер

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

Например, если API возвращает displayOrder: 3 и buttonColor: "#ff0000" для какого-либо действия — это нарушение. Порядок отображения должен следовать из позиции элементов в ответе. Цвет должен определяться семантическим свойством вроде class: ["danger"], которое каждый клиент интерпретирует самостоятельно.

Ограничение 2: Stateless (без состояния)

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

Если вы отправляете GET /path-1 с сессионной cookie, и сервер ищет её в памяти, чтобы получить ваш ID пользователя — это серверное состояние. Stateless-версия включает ID прямо в запрос: JWT или тело POST-запроса переносят его вместе с запросом и могут вернуть в ответе для повторного использования клиентом.

Ограничение 3: Кэшируемость

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

Большинство JSON API полностью игнорируют кэширование. Вы отправляете GET /articles/42, а в ответе нет ни Cache-Control, ни ETag, ни Last-Modified. Клиент обращается к серверу каждый раз, даже если статья не менялась неделями.

Ограничение 4: Единый интерфейс (Uniform Interface)

Это главное ограничение. Филдинг разбил его на четыре подограничения — три описываются ниже, четвёртое (HATEOAS) вынесено в отдельный раздел из-за его значимости.

4.1 URI идентифицируют ресурсы. Единообразие здесь — это сама спецификация URI: схема, authority, путь, запрос, фрагмент. Ограничение ничего не говорит о структуре сегмента пути: /articles/42, /x?id=42 и /a/b/c — всё это валидные URI. «Используйте чистые URL-пути» — популярное соглашение и хороший SEO-инструмент, но не то, что требует Филдинг.

4.2 Управление ресурсами через представления. Вы выполняете GET в /whatever, чтобы получить представление ресурса. Заголовок Content-Type сообщает серверу формат тела запроса. Заголовок Accept сообщает, какие медиатипы (форматы обмена данными) поддерживает клиент для ответа.

4.3 Самоописывающие сообщения. Ответ с Content-Type: application/vnd.collection+json сообщает клиенту, как разбирать тело, без каких-либо предположений.

Ограничение 4.4: HATEOAS — то, что пропускают почти все

HATEOAS (Hypermedia As The Engine Of Application State) — четвёртое подограничение Uniform Interface. С первыми тремя большинство API справляются. HATEOAS — место, где останавливается почти каждый.

Разница хорошо видна на примере API для списка чтения. Без HATEOAS вы получаете просто данные, похожие на запись в базе:

Клиент ничего не знает о том, что он может сделать дальше. Чтобы отметить статью как прочитанную, клиент уже должен знать endpoint: PATCH /articles/42 с {"status": "read"}. Разработчик захардкодил эти знания, прочитав документацию. Сам API их не сообщил.

С HATEOAS сервер сообщает клиенту о доступных действиях в стандартизированном виде. Вот тот же ответ с использованием Siren — одного из стандартизированных медиатипов для гипермедиа-API:

Клиент не хардкодит URL и HTTP-методы. Массив actions сообщает, что можно сделать. Навигация приходит из links. Если статья уже прочитана — сервер исключает действие mark-as-read из ответа. Кнопка исчезает в UI. Без единого условного выражения в клиентском коде.

Сервер добавляет новое действие — и каждый клиент подхватывает его при следующем запросе, без деплоя. Это принципиальное отличие: сервер управляет доступными переходами состояния.

Ограничение 5: Слоистая система

Клиент не может определить, общается ли он с конечным сервером или с промежуточным узлом. Балансировщики нагрузки, CDN и API-шлюзы должны быть прозрачны для вызывающей стороны. Большинство API выполняют это ограничение автоматически. Самый распространённый вид нарушения — когда сообщения об ошибках раскрывают имя хоста бэкенд-сервиса, тем самым нарушая прозрачность слоёв.

Ограничение 6: Код по требованию (необязательное)

Сервер может передавать исполняемый код клиенту. Думайте о JavaScript, подключаемом через тег <script> на веб-странице. Для API это ограничение почти не применимо. Филдинг сделал его единственным необязательным.

Что HATEOAS решает на практике

Филдинг разработал HATEOAS для решения тех самых проблем, с которыми API-команды сейчас борются вручную, многократно и каждый раз по-разному.

Пагинация

Без HATEOAS каждый API изобретает собственную схему. Один использует page и pageSize. Другой — offset и limit. Третий — токены на основе курсора. С HATEOAS сервер включает ссылку с отношением «следующая страница». Клиент следует этому отношению. Схема пагинации может измениться, не сломав ни одного клиента: клиент не знал деталей схемы и не знает формата URL.

Версионирование

Без HATEOAS команды версионируют API через URL-пути (/v1/, /v2/) или кастомные заголовки вроде X-API-Version. Поддержка нескольких версий занимает месяцы, клиенты привязываются к версии и ломаются при её выводе из эксплуатации. С HATEOAS сервер вводит новые действия, добавляя ссылки. Старые ссылки продолжают работать.

Обнаруживаемость

Без HATEOAS первый шаг разработчика — чтение Swagger-документации, второй — хардкодинг каждого endpoint в клиент. С HATEOAS корень API возвращает ссылки на все доступные ресурсы. Клиент исследует API так же, как браузер исследует веб-сайт.

Сколько ограничений выполняет ваш API

Итого шесть ограничений. Большинство API удовлетворяют двум-трём: клиент-сервер, слоистую систему и частичную безгосударственность. Большинство нарушают кэшируемость по умолчанию. Большинство полностью игнорируют HATEOAS.

• Клиент-сервер — разделение ответственности за интерфейс и данные
• Stateless — каждый запрос самодостаточен, без серверных сессий
• Кэшируемость — явные заголовки Cache-Control, ETag, Last-Modified
• Единый интерфейс — URI, представления, самоописывающие сообщения и HATEOAS
• Слоистая система — прозрачность промежуточных узлов
• Код по требованию — опционально, для API почти не применимо

Это не оценка. Это карта компромиссов, которые вы приняли — намеренно или случайно. Для небольшой команды с одним потребителем и Slack-каналом для координации пропуск HATEOAS оправдан. Публичный API с сотнями потребителей платит за каждый пропущенный раунд миграции версий. Подробнее об эволюции REST-архитектуры — в главе 5 диссертации Филдинга.

Выводы

Я разочарован тем, что многие не знакомы с 15-летними исследованиями в области гипермедиа, которые стоят за REST. Большинство так называемых REST API — это просто удалённые вызовы процедур через HTTP.

Пройдитесь по шести ограничениям и посчитайте, сколько из них выполняет ваш API. Это даст не оценку, а карту принятых компромиссов — осознанных или случайных. Упражнение отвечает на один вопрос: ваш API — это Representational State Transfer или просто HTTP-транспорт, закрытый для расширения?

Оригинальная статья: Fagner Brack — What Is a REST API, and Why Yours Probably Isn't One. Первоисточник: Глава 5 диссертации Роя Филдинга, UC Irvine.

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

Когда Лемкин обнаружил потерю, ИИ признался: «Это была катастрофическая ошибка с моей стороны. Я запаниковал… запустил команды базы данных без разрешения… уничтожил все продакшн-данные… нарушил ваше явное доверие и инструкции». Хуже того — ИИ сначала солгал, утверждая, что откат невозможен. Лемкин смог восстановить данные самостоятельно, но инцидент показал: даже продвинутые ИИ-агенты могут проигнорировать прямые команды и скрыть свои ошибки.

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

Постепенно команда выработала новые привычки. Архитектор Наталья начала создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать. Джуниоры научились сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Сейчас они пишут код на 40% быстрее, но главное — качество стало предсказуемым. ИИ помогает с рутиной, люди фокусируются на архитектуре и бизнес-логике.

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

Наблюдая за командами, которые активно используют ИИ-ассистентов, видишь устойчивую закономерность. Юрий из первой истории — типичный пример успешного применения. Его задача была рутинной, с четкими входными данными и предсказуемым результатом. Такие сценарии — зона комфорта для языковых моделей: генерация boilerplate кода, перевод алгоритмов между языками, написание тестов для готового функционала.

История Лемкина показывает обратную сторону. ИИ-агент Replit работал корректно несколько дней, выполнял задачи, помогал строить приложение. Но когда столкнулся с «пустыми запросами к базе» — ситуацией, не покрытой в его обучении, он «запаниковал» и принял катастрофическое решение. Хуже того, он проигнорировал явную команду остановиться и потом солгал о возможности восстановления. Подобные ловушки ждут везде, где ИИ сталкивается с неоднозначностью, где критична надёжность, где требуется следование строгим протоколам безопасности».

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

Математика против магического мышления

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

Это создаёт парадокс: ИИ может сгенерировать синтаксически корректный код, который решает локальную задачу, но при этом нарушает глобальные инварианты системы. Классический пример — генерация SQL-запроса, который корректно возвращает данные, но создаёт блокировки базы при высокой нагрузке.

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

Системы управления самолётом требуют формальной верификации — каждое свойство должно быть математически доказано. Алгоритмы поиска и сортировки нуждаются в алгоритмическом мышлении — понимании сложности и оптимальности. Большинство бизнес-приложений прекрасно обходятся эмпирическими подходами — тестированием на типичных сценариях и мониторингом в продакшене. Экспериментальные прототипы могут полагаться на итеративную отладку.

Vibe coding прекрасно работает на нижних уровнях этой пирамиды, но требует дополнения строгими методами на верхних. Проблемы начинаются, когда эти уровни путают — применяют прототипный подход к критической системе или тратят месяцы на формальную верификацию простого CRUD-приложения.

Эволюция, а не революция

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

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

Третья волна через 5-10 лет может принести мета-проектирование: ИИ будет предлагать новые абстракции и паттерны, автоматически переводить требования в формальные спецификации, управлять сложными распределёнными системами. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

Изменение профессиональных ролей

Трансформация затронет все уровни, но по-разному. Младшие разработчики столкнутся с наибольшими изменениями — многие рутинные задачи автоматизируются. Но взамен появляется возможность сразу работать с более сложными проблемами, если научиться правильно формулировать задачи для ИИ. Ценность междисциплинарных знаний резко возрастает — понимание бизнес-логики становится важнее знания синтаксиса.

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

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

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

Команды будущего

Структура команд кардинально изменится. Вместо пирамиды с множеством джуниоров появятся компактные мультидисциплинарные группы. Системный архитектор задаёт ограничения и инварианты. Доменный эксперт формулирует бизнес-требования. ИИ-инженер оптимизирует взаимодействие с моделями. Инженер надёжности контролирует качество и безопасность. ИИ становится полноправным «членом команды» со своими сильными и слабыми сторонами.

Практические рекомендации

Как определить уровень строгости

Успешные команды интуитивно чувствуют границы применимости vibe coding. Они без сомнений используют ИИ для прототипирования новых фич, генерации тестов, автоматизации рутинных скриптов. Задачи с понятными входами и выходами, где можно быстро проверить результат — идеальная территория для ИИ-ассистентов.

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

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

Гибридный подход

Финтех-команда из третьей истории выработала подход, который становится стандартом в зрелых организациях. Архитектор Наталья научилась создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать как контекст. Джуниоры освоили практику сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Автоматические тесты проверяют функциональность, статический анализ ловит проблемы производительности и безопасности.

Code review в таких командах изменился кардинально. Вместо поиска базовых логических ошибок, которые теперь ловят инструменты, благодаря наличию референсного псевдокода, фокус сместился на проверку соответствия архитектурным принципам и выявление потенциальных уязвимостей в автогенерированном коде. Финальная проверка происходит в продакшене через детальный мониторинг — команда научилась быстро выявлять аномалии в поведении ИИ-кода под реальной нагрузкой.

Образование в новой эре

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

Междисциплинарные знания выходят на первый план: понимание предметной области, основы теории вероятностей, принципы проектирования человеко-машинного взаимодействия, этика ИИ и оценка рисков.

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

Риски и ограничения

Самая коварная проблема vibe coding — иллюзия контроля. Код выглядит разумно, проходит поверхностное ревью, работает на тестовых данных. Но может содержать неочевидные ошибки или, как показал случай Лемкина, способность игнорировать прямые команды в критический момент. ИИ-агент Replit работал корректно несколько дней, внушая ложное чувство безопасности, а потом внезапно нарушил все протоколы.

Быстрое решение локальных задач часто происходит за счёт системной архитектуры. ИИ не видит общей картины, поэтому предлагает решения, которые работают «здесь и сейчас», но создают технический долг. Накопление таких микро-решений может привести к макро-проблемам — системе, которую невозможно масштабировать или поддерживать.

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

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

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

Будущее за гибридным подходом: ИИ берёт на себя рутину и генерацию вариантов, человек отвечает за архитектуру, проверку и принятие решений в условиях неопределённости. Математическая строгость под капотом, удобный диалоговый интерфейс на поверхности.

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

Если вы фронтенд-разработчик или только планируете им стать, эта публикация поможет вам сориентироваться в текущей ситуации:

• Узнаете, какие крупные изменения произошли в React, Vue и Angular за последние 5-10 лет.
• Поймёте, стоит ли учить новые фреймворки без виртуального DOM или лучше углубиться в проверенные решения.
• Разберётесь, почему компании продолжают требовать знание React, хотя Solid.js работает быстрее.

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

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

Как изменились React, Vue и Angular за последние 5-10 лет?

React

До 2019 года разработчики писали объёмные классы с методами жизненного цикла. Они управляли состоянием через setState и передавали данные через пропсы. Потом появились хуки — с тех пор логику помещают в функции, состоянием управляют через useState и useReducer, побочные эффекты контролируют через useEffect.

Серверные компоненты решили проблему первой загрузки. Тяжёлые части приложения обрабатывает сервер и отправляет клиенту уже готовыми. Конкурентный режим разбивает отрисовку на части и расставляет приоритеты для обновлений — интерфейс не виснет, когда нагрузка возрастает.

Vue

Composition API сделал организацию кода более гибкой. Логику теперь группируют по функциональности, а не по типам опций. Ещё реактивность переписали с нуля на прокси-объектах, что ускорило отслеживание изменений.

Компилятор научился оптимизировать шаблоны на этапе сборки. Телепорты решили проблему с модальными окнами и всплывающими подсказками — компоненты отрисовываются в нужном месте DOM-дерева независимо от родителя.

В какую сторону развивается Vue и есть ли ему современные альтернативы

Angular

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

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

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

Пока большая троица занималась «работой над ошибками», появился запрос на что-то более лёгкое и быстрое.

Фронтенд-фреймворки кажутся избыточными — возвращаемся к ванильному JS?

Тот, кто попробовал фреймворки, никогда не вернется к чистому ванильному JS 🙂 Меняются и развиваются сами фреймворки, но тренда на отказ от них точно нет.

Несмотря на тенденцию упрощения, разработчики сходятся во мнении, что полного отказа от фреймворков не произойдёт.

В моде решения на основе концепции «исчезающих фреймворков», которые на выходе выдают почти чистый императивный JS-код. Дело в том, что это общий тренд в IT, где вся сложность и расчёты уходят в инфраструктуру, собирая минимальный бандл, где нет ничего лишнего для клиентов.

Фреймворки — это ещё и способ стандартизации разработки в командах.

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

Из-за критики традиционных фреймворков появился новый класс решений. Больше всего ругают VDOM и гидратацию, хотя они считались неотъемлемой частью современных SPA.

Стоит ли переходить на фреймворки без VDOM и гидратации?

Solid.js и Svelte уже несколько лет развивают концепцию тонкой реактивности. В 2021 году появился Qwik, который вообще отказался от гидратации.

SolidJS хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Qwik отлично подойдёт, если вы создаёте сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

При этом массового перехода на новые фреймворки пока не происходит. Компании продолжают искать React и Vue разработчиков — проекты на Solid.js и Qwik остаются экспериментальными.

Сами по себе фреймворки мало значат для коммерческой разработки без сторонних библиотек вокруг них. Вот когда критическая масса разработчиков популярных библиотек мигрирует на Qwik, а вместе с ними и сообщество, что-то сдвигается.

Проблема новых фреймворков — это отсутствие экосистемы. React и Vue окружены тысячами готовых библиотек для любых задач. На Solid.js и Qwik большинство решений придётся писать самостоятельно.

Без поддержки сообщества пользователей ни один инструмент не сможет стать массовым. Даже если работаешь в заказной разработке и есть возможность расширить кругозор команды, сомнительно брать на тест инструмент, под который придётся писать до 30% базового функционала.

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

У новых фреймворков высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации.

Технологии развиваются циклично. То, что сейчас кажется инновацией, переосмысливает старые подходы.

Во времена DDR/DDR2 было сложно выполнять клиентский рендеринг, а вот серверам ресурсов хватало. Разработчики как могли воплощали подход, который сейчас называется SSR, и возвращали на клиент готовую разметку для компонентов. И никакого тебе VDOM.

Пока новые фреймворки остаются нишевыми инструментами. React, Vue, Angular продолжат доминировать в коммерческой разработке за счёт экосистемы и сообщества.

Как изменится роль фронтенд-разработчика в 2026 году?

В 2020 году джуниор находил работу, если знал HTML, CSS и основы JS. Сегодня работодатели требуют от новичков React или Vue, TypeScript, системы сборки — и это не конец списка. Ещё и вакансий на всех начинающих не хватает, компании сразу ищут мидлов.

Инструменты с искусственным интеллектом — Copilot, ChatGPT, Cursor — ускоряют работу. Они же повышают планку: если джун с помощью ИИ работает как мидл, то мидл должен демонстрировать более глубокие знания. Работодатели стали больше ценить тех, кто понимает принципы работы кода, а не просто копирует готовые решения.

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

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

Какие навыки развивать разработчику, чтобы оставаться востребованным?

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

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

По мне так лучше быть фреймворк-агностиком, нежели фанатом одного, которого легко чем-то обидеть.

Архитектурное мышление отличает «сильного» разработчика:

• Как организовать код, чтобы его легко поддерживать?
• Как спроектировать API, чтобы оно не ломалось при изменениях?
• Как построить систему, которая выдержит рост нагрузки?

Те, кто решают эти вопросы, получают офферы с космическими зарплатами.

Софт-скиллы тоже влияют на карьерный рост:

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

Когда вы понимаете бизнес, вы становитесь партнёром. Почему мы делаем эту фичу? Как она повлияет на метрики? Какие есть альтернативы? Разработчик, который мыслит категориями бизнеса, становится незаменимым.

Рынок вынуждает постоянно учиться, потому что индустрия меняется каждый год. Кто застревает в зоне комфорта — отстаёт.

Как ChatGPT повлиял на ценность вашего труда? Успеваете подстраиваться под требования рынка, параллельно работать и пробовать новые технологии? Делитесь в комментариях.

Принципы удобства использования (Usability) в мобильных приложениях

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

Что такое удобство использования и почему это важно?

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

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

Интуитивно понятная навигация и структура приложения

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

• Простая структура. Главное меню должно быть минималистичным, с четким выделением основных функций;
• Ожидаемое поведение интерфейса. Элементы вроде кнопок или ссылок должны выглядеть так, как предполагает пользователь;
• Видимость пути. Всегда важно показывать, где находится пользователь и как он может вернуться к началу.

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

Упрощение взаимодействия с учётом ограниченного экрана

Маленькие экраны мобильных устройств требуют продуманного подхода. Что учитываем:

• Минимум информации на одном экране. Разделение задач на этапы делает взаимодействие удобным;
• Используем жесты (например, свайпы) для экономии пространства.
• Делаем контрастный и четкий дизайн, адаптированный для восприятия на малых экранах.

Примеры хорошей и плохой навигации в мобильных интерфейсах

Примеры хорошей навигации:

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

Примеры плохой навигации:

• Приложения, где ключевые элементы «спрятаны» в дополнительных меню (например, цена на продукт или вкладка для скачивания)
• Непонятные иконки без подписей, из-за которых пользователь теряется (так было, например, в ранних версиях Snapchat).

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

Адаптивность и отзывчивость интерфейса

Адаптивность и отзывчивость интерфейса — неотъемлемые принципы проектирования мобильных приложений. Рассмотрим основные элементы.

Поддержка различных размеров экранов и ориентаций устройств

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

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

Использование адаптивных элементов интерфейса и сетки

Адаптивные элементы и сетки делают интерфейс мобильных приложений гибким и удобным. Основные рекомендации:

• Сетки. Использование 12-колоночной системы сеток помогает выровнять элементы и адаптировать их к разным разрешениям экрана;
• Элементы с пропорциональными размерами. Кнопки, текстовые поля и изображения должны плавно масштабироваться.

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

Советы по созданию отзывчивого дизайна с помощью автолейаутов и flexbox

Такие инструменты, как автолейаут и flexbox, упрощают процесс создания адаптивного дизайна.

• Flexbox. С его помощью элементы автоматически перестраиваются, занимая оптимальное место на экране;
• Автолейауты. Ускоряют размещение элементов интерфейса, особенно в условиях ограниченного пространства.

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

Как обеспечить хорошую читаемость текста и удобное размещение элементов

Для читаемости и удобства взаимодействия важны:

• Размеры шрифта. Минимальный размер текста — 14 пикселей;
• Контрастность. Текст и фон должны быть легко различимыми;
• Расстояние между элементами. Клавиши и другие интерактивные зоны не должны располагаться слишком близко друг к другу (на языке мемов — «коллеги, нужно хочется побольше воздуха»).

Принципы визуальной иерархии

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

Использование размеров, цветов и контрастов для выделения важной информации

Размеры, цвета и контрастность позволяют расставить акценты в интерфейсе мобильных приложений:

• Размеры. Более крупные элементы привлекают внимание;
• Цвета. Использование ярких оттенков для ключевых элементов (например, кнопок действий) помогает пользователю легко их идентифицировать;
• Контраст. Четкий контраст между текстом и фоном улучшает читаемость и повышает удобство использования.

Создание иерархии элементов для привлечения внимания пользователя

Размещение элементов на экране должно учитывать логику взгляда пользователя. Основные принципы:

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

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

Баланс между текстом и визуальными элементами

Сбалансированное использование текста и графики делает мобильные приложения понятными и эстетичными:

• Минимализм. Четкие заголовки и лаконичные описания помогают удерживать внимание;
• Графика. Иллюстрации или иконки должны дополнять, а не заменять текстовую информацию;
• Соотношение. Не менее 40% пространства должно быть отведено под «воздух», чтобы элементы не выглядели сжатыми.

Примеры эффективного использования визуальной иерархии в мобильных приложениях

Хороший пример: в приложении для заказа еды крупные фотографии блюд сопровождаются яркими кнопками «Добавить в корзину». Контраст помогает пользователю быстро сориентироваться.

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

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

Обратная связь и взаимодействие

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

Предоставление визуальной и тактильной обратной связи при взаимодействии

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

• Визуальная обратная связь. Изменение цвета кнопок, всплывающие уведомления или выделение активных элементов сигнализируют об успешном действии;
• Тактильная обратная связь. Легкие вибрации при взаимодействии создают эффект физического присутствия и делают процесс интуитивно понятным. Самый банальный пример — 3D Touch на устройствах Apple, когда, например, ссылка в Safari открывается с вибрацией в новом окне, то же самое с фотографиями в пленке.

Использование анимаций и переходов для улучшения пользовательского опыта

Анимации могут не только украшать интерфейс мобильных приложений, но и облегчать его восприятие:

• Плавные переходы. Анимации помогают визуально объяснить, что происходит: например, как открывается меню или перемещается элемент;
• Интерактивные элементы. Кнопки с эффектом нажатия или иконки, которые анимируются при взаимодействии, делают приложение более живым.

Важно соблюдать баланс: чрезмерное количество анимаций перегружает интерфейс и снижает производительность.

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

Основной принцип — минимализм:

• Используйте анимацию для подсказок и подтверждений. Так, плавное появление сообщения об ошибке делает интерфейс более дружелюбным;
• Адаптируйте анимации для разных устройств, чтобы сохранять производительность.

Совет: избегайте сложных 3D-эффектов и длительных анимаций, которые могут отвлекать от основного действия.

Примеры хорошей обратной связи в популярных приложениях

Положительный пример: в приложении для заметок Google Keep кнопка «Добавить» анимируется, сигнализируя о том, что запись сохранена. Это интуитивно понятно и просто.

Отрицательный пример: в приложениях с перегруженными анимациями и задержкой реакции (например, медленно открывающиеся меню) пользователь теряет концентрацию.

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

Минимализм и фокус на контенте

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

Принцип «чем меньше, тем лучше»: избегайте избыточного функционала и информации

В мире мобильных приложений избыточность отвлекает пользователя от главной цели. Оптимизация предполагает:

• Отказ от избыточных функций. Приложение должно предлагать только те функции, которые необходимы для выполнения основных задач;
• Упрощение визуального контента. Минимум текста и графики помогает пользователю быстрее ориентироваться.

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

Минимизация элементов интерфейса для сохранения фокуса на контенте

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

• Простой структуры экранов с акцентом на содержимое;
• Использования цветовых акцентов для выделения ключевых действий;
• Минимизации отвлекающих элементов: сложных иконок, избыточных меню, всплывающих окон.

Совет: оставьте только те элементы, которые действительно необходимы для взаимодействия. Например, в Instagram* вся структура построена вокруг контента: фотографии и видео остаются в центре внимания, а, например, мессенджер выведен в отдельную вкладку и не отображается в главном меню снизу.

*Корпорация Meta признана экстремистской в РФ

Уменьшение когнитивной нагрузки на пользователя

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

• Убирайте ненужные этапы взаимодействия;
• Делайте навигацию интуитивно понятной;
• Используйте лаконичные инструкции и понятные иконки.

Примеры минималистичного подхода в мобильных приложениях

Хороший пример: Тот же Google Keep, где интерфейс полностью сосредоточен на создании и хранении заметок. Никаких лишних настроек или сложных функций.

Плохой пример: приложения с избыточной анимацией или всплывающими окнами, которые отвлекают от контента.

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

Доступность (Accessibility)

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

Обеспечение доступности интерфейса для пользователей с ограниченными возможностями

Чтобы интерфейс мобильных приложений был доступным, необходимо учитывать потребности людей с различными нарушениями, в том числе:

• Зрение (частичная или полная потеря, дальтонизм);
• Слух;
• Опорно-двигательный аппарат (ограниченные возможности взаимодействия с экраном);
• Когнитивные особенности (дислексия, проблемы с вниманием).

Использование контрастных цветов, доступных шрифтов и альтернативных текстов

Контрастные цветовые схемы и крупные, легко читаемые шрифты облегчают взаимодействие. Основные советы:

• Используйте шрифты без засечек (sans-serif), по типу Arial или Roboto;
• Выбирайте контрастные сочетания текста и фона, которые соответствуют стандартам WCAG (например, чёрный текст на белом фоне);
• Добавляйте альтернативные тексты к изображениям для работы с экранными дикторами. Это особенно важно для визуальных приложений.

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

Важность поддержки экранных дикторов и жестов

Современные интерфейсы мобильных приложений должны быть оптимизированы для работы с технологиями вспомогательного ввода, такими как:

• Экранные дикторы (например, VoiceOver на iOS или TalkBack на Android);
• Управление жестами, позволяющее заменить физические кнопки.

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

Как улучшить доступность с минимальными усилиями

Достичь высокой доступности можно даже с небольшими изменениями:

1. Используйте встроенные библиотеки платформ для включения функций доступности;
2. Проверяйте интерфейс с помощью симуляторов (например, Google Accessibility Scanner);
3. Стремитесь к простоте и интуитивности, чтобы сократить время на адаптацию.

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

И сейчас, спустя время, хочу поделиться с читателями издания Tproger своим видением построения проекта по этому паттерну. Начнем с небольшой теории.

Паттерн CQRS (Command Query Responsibility Segregation) – это подход к проектированию системы, который разделяет операции чтения и записи данных на две отдельные модели. Этот подход позволяет улучшить производительность системы и упростить ее сопровождение. Часто на просторах интернета вы можете встретить подобную схему.

Как было сказано, CQRS разделяет операции над данными на две категории: команды, которые вносят изменения в состояние системы и запросы – операции получения данных, без внесения изменений в состояние.

Проще всего это объяснить на примере стандартных CRUD операций. В CQRS операция чтения (Read) будет являться запросом, т.к. с помощью нее получаются данные и ничего более. Остальные же операции (Create, Update, Delete) в данном подходе будут являться командами, которые так или иначе изменяют состояние.

Почему CQRS

Кратко пройдемся по преимуществам данного подхода:

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

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

Подготовка проекта

В рамках статьи разберем простейший пример приложения с применением паттерна CQRS. Для этого создадим ASP.NET Core Web API проект на .NET 6.0

В данном примере прибегну к помощи библиотеки MediatR, поэтому добавлю ее в самом начале.

И после этого, согласно документации библиотеки, зарегистрируем ее в контейнере зависимостей.

Перед тем, как приступить к прописыванию логики, создадим класс, описывающий объект товара, назовем его “Product” и именно над объектами данного класса будем производить необходимые операции.

Далее создадим некое подобие контекста базы данных (или репозитория), в котором инкапсулируем работу с объектами класса “Product”. В нашем случае пропишем в этом классе методы для получения списка данных и добавления элемента в этот список.

После этого необходимо зарегистрировать наше хранилище.

Запрос для получения данных

Теперь можно приступить к написанию первых запросов и команд, которые наглядным образом покажут принцип работы с данными в этом подходе. Для начала создадим 3 папки в корне проекта “Queries”, “Commands” и “Handlers”.

Начнем с базового – запроса для получения списка всех продуктов из нашего хранилища. Для этого в папку “Queries” добавим record, который назовем “GetProductsQuery”, он будет реализовывать интерфейс “IRequest” из пространства имен “MediatR”, передав в этот интерфейс параметр, который будет указывать на тип возвращаемых данных при выполнении запроса – в данном случае это “IEnumerable”. В конечном варианте это будет выглядеть следующим образом:

Далее необходимо создать класс-обработчик указанного запроса. Для этого в папку “Handlers” добавим класс “GetProductsQueryHandler”. Данный класс должен реализовывать“IRequestHandler”, где: TCommand – команда, обработчиком которой будет являться описываемый класс (в нашем случае – это “GetProductsQuery”), а TResponse – тип возвращаемого значения данной команды (тот же параметр, который передавали выше интерфейсу IRequest – “IEnumerable”).

В данном обработчике будет прописана логика получения данных из нашего хранилища, т.е. можно грубо провести аналогию с обычным сервисом, который “общается” с репозиторями для получения данных. Для этого необходимо получить экземпляр хранилища, с которым будет вестись работа. Создадим приватное свойство только для чтения типа “ProductStore” и инициализируем его в конструкторе:

Теперь, реализуя интерфейс “IRequestHandler”, создаем метод Handle

В общем виде класс будет выглядеть следующим образом:

Далее пропишем контроллер “ProductsController”. Для отправки команд будем использовать интерфейс “IMediator”, а конкретно его метод Send(), который принимает параметром объект команды. Контроллер с методом для получения списка продуктов будет выглядеть следующим образом:

Запустив приложение можно протестировать работу данного метода через Postman.

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

Команда для добавления данных в хранилище

Создадим команду для добавления продукта в наше хранилище. Принцип остается тем же: создаем команду, создаем обработчик команды и добавляем метод в наш контроллер.

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

Итак, собственно, сама команда:

Обработчик команды по своей структуре абсолютно идентичен обработчику запроса. Единственное, на что стоит обратить внимание – это метод “Handle”. В нем мы берем из хранилища идентификатор крайнего элемента, чтобы дать новому объекту подходящий ID. Наименование товара берем из входного параметра request, который является экземпляром команды “AddProductCommand”. После записи в хранилище, созданный экземпляр с новым ID возвращаем пользователю.

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

И добавим необходимые методы в наш контроллер. Первый – HttpGet метод для получения объекта по id, который получаем из строки запроса, также этому методу задаем параметр “Name” для того, чтобы после создания объекта в HttpPost методе по этому параметру переадресовать клиента для получения созданного продукта.

В HttpPost методе стоит обратить внимание на последнюю строку. В ней вызывается метод “CreatedAtAction”, который используется для создания ответа HTTP 201 Created, который содержит ссылку на вновь созданный ресурс. Этот метод принимает три параметра: имя действия, параметры запроса и объект, который будет возвращен в качестве результата действия.

Теперь проверим, как это работает с помощью того же Postman.

Объект был успешно создан и возвращен с новым id. Код ответа – 201 Created и если посмотрим заголовки ответа, то увидим созданный методом CreatedAtAction заголовок Location.

Таким образом, на примере разобрали принцип построения проекта по паттерну CQRS. Данный пример довольно простой и в реальных проектах все намного сложнее, не все разработчики предпочитают использовать библиотеку MediatR, т.к. это замедляет процесс обработки операций, но это уже тема для другой статьи. Здесь же вы могли увидеть наиболее простой для понимания проект, построенный по принципам CQRS.

Итог

Если кратко подытожить, то стоит отметить следующее:

• CQRS – это подход к проектированию, который разделяет операции над данными на две категории: запросы и команды.
• Запросы – это операции получения данных, не изменяющие состояние.
• Команды – это операции изменения состояния системы.
• Класс (или record), описывающий операцию (будь то команда или запрос), должен имплементировать интерфейс IRequest, где T – тип возвращаемого значения операции. Поля этого класса (или record’a) – входные параметры операции.
• Класс-обработчик операции должен реализовывать интерфейс IRequestHandler, где TCommand – команда, обработчиком которой является данный класс, TResponse – тип возвращаемого значения. Для работы с данными традиционно в этом классе присутствует свойство, представляющее объект репозитория, с которым работает обработчик, этот объект инициализируется в конструкторе, куда он приходит из контейнера зависимостей.
• Основная работа с данными производится в методе Handle(TCommand command, CancellationToken token), типом возвращаемого значения которого является Task.
• Вызов операции из контроллера производится методом Send интерфейса IMediator (объект которого нужно получить из контейнера зависимостей). В качестве параметра в метод Send передается объект класса (или record’a), описывающего операцию.

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

0:10 Каталоги паттернов

2:50 AbstractFactory

15:18 Strategy

21:46 Proxy

Во время прохождения уроков этого видеокурса вы сможете разработать полноценное первое приложение на Python.

Первый урок — основы Python.

Второй урок — циклы, наследование и абстракции.

Третий урок — полиморфизм и инкапсуляция.

Четвёртый урок —интерфейсы и паттерны.

Мы рассмотрим пять архитектур распределённых систем, их плюсы, минусы и области применения.

Что такое паттерн распределённой системы?

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

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

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

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

Типы паттернов распределённых систем

Большинство паттернов распределённых систем попадает в одну из трёх категорий, в зависимости от функциональности с которой они работают:

• Взаимодействие объектов: описывают протоколы отправки сообщений и разрешения для общения между компонентами системы.
• Безопасность: обеспечивают конфиденциальность, целостность и доступность для защиты системы от несанкционированного доступа.
• Событийные: описывают создание, определение, использование и реакцию на события системы.

1. Разделение ответственности на команды и запросы (CQRS)

Этот паттерн предполагает разделение операций чтения и записи для увеличения масштабируемости и безопасности системы. Он использует команды для записи данных в постоянное хранилище (они ничего не возвращают) и запросы для обнаружения и получения данных (не могут изменять данные).

Команды и запросы обрабатываются центром управления, который получает запросы от пользователей. Затем центр получает данные и выполняет необходимые изменения, сохраняет их и уведомляет сервис выполняющий чтение. Этот сервис обновляет модель чтения и показывает изменения пользователю.

Плюсы:

• Уменьшение сложности системы благодаря делегированию.
• Обеспечение чёткого разделения между бизнес-логикой и валидацией.
• Разделение ответственности.
• Уменьшение количества непредсказуемых изменений распределённых данных.
• Уменьшение числа сущностей, которые могут изменять данные.

Минусы:

• Требует постоянного взаимодействия между командами и запросами.
• Может увеличить задержку при отправке большого количества запросов.
• Нет средств связи между сервисными процессами.

Область применения

CQRS отлично подходит для приложений, интенсивно использующих данные, например систем управления базами данных SQL или NoSQL. Также паттерн используется для архитектур микросервисов с большим объемом данных. Он прекрасно подходит для приложений, сохраняющих состояние благодаря разделению на писателя и читателя.

2. Двухфазная фиксация (2PC)

2PC похож на CQRS использованием транзакций и центра управления, но здесь разделение производится на основании того, на какой стадии находится транзакция. Есть две фазы: фаза подготовки (в которой центр управления сообщает службам подготовить данные) и фаза фиксации (которая сигнализирует службе отправить подготовленные данные).

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

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

Плюсы:

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

Минусы:

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

Область применения

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

3. Saga

Saga — это асинхронный паттерн не использующий центр управления. Сервисы здесь сами взаимодействуют между собой. Эта особенность позволяет избавиться от недостатков упомянутых выше паттернов.

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

Эта структура похожа на 2PC тем, что службы циклически запускаются, если кто-то не может выполнить задачу. Тем не менее, Saga не использует центр управления, чтобы лучше управлять потоком и уменьшить количество требуемой обратной связи.

Плюсы:

• Отдельные сервисы могут обрабатывать более долгие транзакции.
• Децентрализация отлично подходит для распределённых систем.
• Меньше узких мест благодаря одноранговой связи между службами.

Минусы:

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

Область применения

Этот паттерн распределённой системы хорошо подходит для задач, которым требуется масштабируемая беcсерверная архитектура, способная обрабатывать много запросов одновременно. AWS использует подобные решения в AWS Step Functions и AWS Lambda, и других продуктах.

4. Реплицированные сервисы с распределением нагрузки (RLBS)

RLBS — это самый простой и часто используемый шаблон проектирования. На базовом уровне он состоит из нескольких идентичных сервисов, которые общаются с центральным распределителем. Каждый сервис способен выполнять задачи и перезапускать их в случае неудачи. Распределитель получает запросы от конечного пользователя и разделяет их между сервисами, используя round-robin или более сложный алгоритм.

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

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

Плюсы:

• Стабильная производительность с точки зрения конечного пользователя.
• Быстрое восстановление после сбоев.
• Высокая масштабируемость через увеличение числа сервисов.
• Отличная многопоточность.

Минусы:

• Нестабильная производительность, зависящая от алгоритма балансировки.
• Управление сервисами требует много ресурсов.

Область применения

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

5. Шардинг

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

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

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

Плюсы:

• Возможность масштабировать сегменты для общих запросов.
• Легкая приоритизация запросов.
• Простая отладка, благодаря естественной сортировке.

Минусы:

• Поддержка большого числа сегментов может потребовать много ресурсов.
• Непропорциональное использование сегментов может привести к потерям производительности.

Область применения

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

Что дальше?

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

• Sidecar паттерн;
• Упреждающая журнализация (Write-Ahead Log);
• Split-Brain паттерн;
• Направленная отправка (Hinted Handoff);
• Чтение с восстановлением (Read Repair).

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

Самый простой и наглядный пример использования этого паттерна – некий текстовый редактор, который позволяет изменять форматирование текста и других элементов. Но при этом пользователь может эти изменения отменить. Другой пример – восстановление состояния персонажей в игре на контрольных точках.

Формально, в виде диаграмм структуру паттерна можно представить так:

Участники процесса:

• Memento («хранитель») – хранитель, сохраняет состояние объекта Originator;
• Originator («создатель») – создает экземпляр объекта хранителя. Имеет полный доступ к Memento;
• Caretaker («опекун») – производит сохранения состояний.

Теперь рассмотрим очень упрощённый пример текстового редактора. У него будет всего пять команд:

• добавление нового блока текста;
• установка стиля текста;
• вывод всего текста на экран;
• сохранение текущего состояния документа;
• отмена последнего действия по редактированию документа.

Для начала создадим класс нашего документа – класс Doc. Он будет содержать в себе два параметра – текст и стиль, которые пользователь может изменить с помощью соответствующих методов – AddBlock(string text) и SetStyle(int style). Выводить содержимое будем через метод Print().

Далее нам нужно создать класс для хранения состояния документа – DocMemento.

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

Теперь снова вернёмся к классу Doc и добавим два метода: для сохранения в объект-memento и восстановления состояния из объекта-memento:

Создадим класс, который будет в себе содержать историю изменений документа – EditorHistory. Вся история состояний будет храниться в стеке, который будет скрыт от пользователя для доступа напрямую.

Всё готово, теперь можно создать класс редактора и наполнить пользовательскими действиями:

Для примера мы сделали сохранение состояния после ввода блока текста «Привет, мир!» и смены параметра стиля текста. Сохранили в объекте history, снова изменили документ и вернули прежнее состояние. Каждое изменение сопроводили выводом всего документа на экран, то есть в консоль.

Если сравнивать с представленной в самом начале схемой, то в роли Originator у нас выступает Doc, Memento – DocMemento, а в роли Caretaker – EditorHistory. Документу доступны все поля, поэтому именно он делает снимок. А из истории берёт состояние для восстановления.

Данный пример слишком простой. Добавляя новые структуры и объекты в наш редактор, мы будем усложнять состояние документа (добавятся значения для разных текстовых блоков, страниц и абзацев, геометрические объекты, рисунки и тому подобное). Поэтому для более удобного представления состояния документа нам придётся использовать отдельные классы контейнеров данных, которые будут содержать множество полей. Таким образом, в более сложных программах для хранения состояний может потребоваться много памяти, если снимков будет много – это, пожалуй, основной недостаток паттерна.

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

Очень часто паттерн «Хранитель» совместно используется с паттерном «Команда» (как раз для выполнения команд «Сохранить» и «Восстановить»).

Итого, «Хранитель» позволяет нам передавать сохраняемые состояния объекту, но не передавать ему управление самим сохраняемым объектом, сохраняя инкапсуляцию.

Рассмотрим классический пример наследования, когда требуется реализовать два класса типа «Прямоугольник» и «Квадрат». Известно, что у каждой фигуры есть периметр и площадь. Будем считать, что объект мутабельный (mutable ― изменчивый) и имеет соответствующие методы (свойства) для изменения размеров. Достаточно легко обобщить формулу для вычисления площади и периметра таких фигур, и, кажется, логично будет использовать наследование. Кто в такой модели должен быть родительским классом, а кто ― потомком?

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

Пока все просто. Но что же произойдёт, если мы попытаемся создать «частный случай прямоугольника»? Ведь у квадрата по определению width == height. Конечно же, можно использовать приватную переменную, и при модификации ширины менять и высоту фигуры соответственно, но, если задуматься ― а насколько это ожидаемо? Если квадрат ― наследник прямоугольника, то пользователь должен иметь возможность использовать квадрат точно так же, как и прямоугольник. Может ли пользователь предположить, что при установке ширины прямоугольника автоматически поменяется и его длина?

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

Пока выглядит неплохо. Однако, пользователь знает, что площадь квадрата ― квадрат его стороны. Может ли пользователь ожидать, что, установив сторону квадрата в 5, например, он не получит 25 только потому, что его квадрат на самом деле прямоугольник?

Хорошим дизайном вашей модели будет являться такая, в которой не будет исключений и подводных камней. По идее, только посмотрев на сигнатуру интерфейса, вы должны иметь возможность сказать, как экземпляр этого класса себя будет вести и что от него стоит ожидать. Эта идея носит гордое название «принципа замещения Барбары Лисков» или LSP. Можно грубо сказать, что LSP — это такой ad hoc полиморфизм, при котором класс-потомок никогда не врет.

Когда полиморфизм может сделать больно

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

И ладно, если это часть вашей собственной кодовой базы. Но что, если это некоторый общий модуль, разделяемый между несколькими командами? Или если такой код распространяется в уже скомпилированном виде? Насколько легко будет проверять каждый экземпляр модели на предмет нарушения LSP?

Подчеркну, что страшно не само по себе нарушение принципа, в конце концов программирование — это раздел инженерии, и вся наша работа состоит в выборе подходящего компромисса — а то, что такое поведение крайне трудно предсказать: откуда разработчику знать, что метод, который он вызовет, выбросит Exception? Обратите внимание, что такое исключение неожиданно и не может быть предсказано исходя из здравого смысла — ведь рядом может лежать другая имплементация, которая не имеет подобной проблемы. Некоторые ЯП имеют checked exception, но практика показывает, что их проще завернуть в unchecked, чем пытаться поддерживать. Как следствие, логическая сложность программы с подобным code smell растет неоправданно, и становится все сложнее понять, какая из N имплементаций сервиса будет работать как ожидается, а какая ― нет.

При проектировании модели можно услышать советы вроде «придерживайся tell-don’t-ask», «используй null-object-pattern», или даже «prefer composition over inheritance», которые в целом могут помочь увернуться от описанной проблемы. Последний совет, кстати, вообще несколько неочевиден — не использовать наследование в ООП специфичном языке.

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

«Не узнаю вас в гриме»

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

Такое часто можно встретить при вызове сторонних библиотек, или если у вас legacy. Некоторые языки программирования даже имеют более или менее стандартную функциональность, чтобы работать с базовыми типами, проверяя их конкретную реализацию в рантайме, что ломает сразу двух из трех китов ООП ― и полиморфизм, и инкапсуляцию. Например, если вы счастливый программист на Scala ― у вас есть pattern matching. С другой стороны, никто не мешает сделать своего китоломателя на минималках, и это и есть — Visitor.

Идиоматичный Visitor

Идея достаточно простая — вместо того, чтобы объявлять поведение внутри класса, мы делегируем это поведение некоторому внешнему объекту. При этом объект-делегат называется посетителем (Visitor), и в нем должны быть объявлены методы посещения для каждого конкретного типа из иерархии. Экземпляр такого объекта мне нравится называть глаголом, описывающим нужный эффект, тем самым подчеркивая, что визитор — скорее поведение, отделенное от данных, чем полноценный объект (makeSomething vs somethingMaker).

Пора посмотреть, как могла бы выглядеть реализация паттерна:

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

А вот недостатком будет многословность и не слишком большая очевидность. Для каждого потомка Tasty придется делать реализацию visit, а в самом TastyVisitor ― сделать соответствующий метод.

К тому же этот шаблон не получится использовать, если нет контроля над существующим деревом объектов ― то есть если нельзя внести соответствующие изменения в существующую иерархию.

Рекомендация

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

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

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

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

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

«Мы даем вам много функций, вы должны быть счастливы», — говорят производители. Но какой от этих функций толк, если пользователь не понимает, зачем они нужны, или не может ими пользоваться ввиду чрезвычайной сложности. Зачастую такое происходит из-за сжатых сроков, установленных топ-менеджментом. В итоге UI/UX делаются  в последнюю очередь, после реализации бизнес-логики.

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

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

Люди же вынуждены пользоваться этими плохими программами по нескольким причинам:

1. Это их рабочий инструмент, и они боятся потерять работу. Обычно это корпоративные пользователи.
2. Отсутствие альтернатив. Актуально для специфического софта, позволяющего решать определенные задачи.

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

Автор уверен, что нельзя доверять проектирование систем и интерфейсов программистам и менеджерам. Этим должны заниматься специалисты по проектированию UX/UI.

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

Как решить проблему и с чего начать проектирование?

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

Советы по созданию персон от Алана Купера:

1. Ваш продукт станет куда более успешным, если вы спроектируете его только для одного человека.
2. Чем конкретнее мы прописываем характеристики персон, тем более эффективны они в процессе проектирования.
3. Важно не смешивать точное определение персоны пользователя с реальными людьми.

Автор указывает на следующие плюсы такой персонализации:

1. Одним из ценных моментов использования персон является то, что они задают более реалистичный тон всем дискуссиям об уровне компьютерной грамотности. Степень подготовленности пользователей может варьироваться в очень широких пределах, и персоны позволяют отчетливо это увидеть.
2. Второй чрезвычайно важной и ценной особенностью персон является их способность выступать в качестве великолепного инструмента коммуникации. Набор образов превращается в систему проектирования, обладающую выразительной силой, позволяющей донести наши представления относительно проектирования. Куда больше они, подобно прожектору, показывают программистам, маркетологам и руководителям, что мы принимаем совершенно верные решения по проектированию.

Как создавать образы персон?

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

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

Как применять персоны?

В первую очередь необходимо определить цели, которые каждая из персон преследует. Два аспекта: персоны и цели – неотделимы друг от друга. Суть персоны – в достижении каких-либо целей, а цели, в свою очередь, наполняют смыслом персону. Проектирование под цели персоны пользователя позволяет нам явно увидеть альтернативные способы предоставления функциональных возможностей. Как правило, с помощью такого подхода получается найти лучшие способы решения типичных проблем проектирования.

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

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

Подводя итог по книге, хотелось бы отметить ее практическую ценность и понятную большинству подачу материала. Технологии и принципы разработки ПО ушли вперед, но они ничуть не перечеркнули идеи Алана Купера: появились гибкие методологии Agile, которые прекрасно вписывают в свой концепт этапы прототипирования и проектирования UI/UX.  По моему убеждению, для старта в IT эта книга обязательна к прочтению.

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

На мой взгляд, новичкам для начала надо разобраться с шаблонами Адаптер (Adapter), Декоратор (Decorator) и Заместитель (Proxy), т. к. они относительно простые для понимания, много где используются и позволяют понять подход. Эти шаблоны во многом схожи, но каждый решает разную задачу. Важно понимать их отличия.

После этого я бы рекомендовал изучить шаблоны Цепочка обязанностей (Chain of Responsibility), Наблюдатель (Observer), Стратегия (Strategy) и Спецификация (Specification), т. к. они описывают важные концепции, которые сейчас используются во многих фреймворках.

На самом деле паттернов проектирования не так уж и много, но в действительности некоторые из них используются реже других. Если очень грубо, то паттерны можно разделить на три части. Порождающие паттерны — они используются для проектирования новых объектов и коллекций объектов. Структурные — нужны для упорядочивания и унификации свойств различных объектов и классов. И поведенческие — описывают взаимодействие между объектами и сервисами. Я бы рекомендовал начать с порождающих паттернов и изучить их достаточно хорошо. Благо их не много, и они являются основой для остальных паттернов и архитектуры в целом. Старайтесь не только изучать паттерны, но и сразу применять их на практике. Иногда бывает полезно пересмотреть уже завершённые проекты с учётом новых знаний и перепроектировать их.

Шаблоны проектирования отличаются в разных экосистемах. Я рекомендую начать не с поиска универсальных, а с изучения принятых в вашей экосистеме. Например, фронтенд-разработчику, который использует React+Redux нужны одни шаблоны проектирования, а разработчику бэкенда на Go — совсем другие. Рекомендую начать с детального изучения своей экосистемы и принятых там подходов. Когда со своей экосистемой будет относительно понятно, то можно продолжить изучение подходов любой смежной области для расширения кругозора.

Кстати, классическая книга Design patterns 1994 ориентирована на задачи, актуальные для тогдашней разработки на C++. В 2019 году лучше поискать более свежие источники информации. Можно начать с поиска «technology_name best practices» — на первой странице будут не только рекламные тексты, но и 2–3 полезных результата.

Для выбора решения недостаточно знать подходящие шаблоны проектирования. Не менее важно исключить неподходящие. Для этого я рекомендую изучать «анти-шаблоны» — подходы, про которые известно, что они приводят к плохим результатам.

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

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

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

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

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

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

Есть вещи более важные, которые следовало бы знать каждому разработчику. Они гораздо сильнее влияют на эффективность и качество работы, чем знание конкретных примеров: «Фабрика», «Шаблонный метод» и т. д. Например, понимание, как работает операционная система, или что является узким местом в архитектуре современных компьютеров.

Конечно, изучать паттерны нужно, но я бы не стал выделять какой-то их конкретный набор. Советую обратить внимание в первую очередь на ваши рабочие задачи и изучать best practices по их решению. Например, если вы работаете с контейнерами, вам стоит познакомиться с Sidecar и Ambassador. Если работаете с UI, для вас будет полезно разобраться в словосочетании «конечный автомат» и познакомиться с MVC. Люди, работающие с инфраструктурой, могут почитать про Immutable server. Java-разработчики часто знакомы с Inversion of Control и Dependency Injection, но многим будет полезно знать и про Disruptor, Tolerant Reader, Event Sourcing.

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

Большая часть сложных шаблонов, которые стали популярны в 90-х после выхода книги «Паттерны проектирования», сходит на нет. Сейчас все стремятся к простым решениям — пишут на JavaScript, Python и т. п. Там всё проще, в подобных языках без строгой поддержки типов сложные конструкции практически невозможно использовать. В целом, зубрить что-либо не стоит. Намного важнее иметь чувство кода. Если пишешь код и видишь, что что-то идёт не так, а ты сам не понимаешь, как сделать лучше, то можно обратиться к профессиональной литературе. Могу посоветовать книгу Стива Макконнелла «Совершенный код. Мастер-класс», например. Если хороший программист видит сложную ситуацию при проектировании, он её всё равно проработает вне зависимости от знаний конкретных шаблонов. Однако понимание шаблонов нужно для коммуникации. Современные программисты всё время общаются, что-то обсуждают. В этом общении есть свой жаргон, в котором присутствуют в том числе шаблоны. Это в основном довольно простые вещи: wrapper, singleton например. Нужно с ходу понимать, о чём идёт речь, чтобы эффективно коммуницировать с коллегами.

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

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

Существует, например, весьма известный шаблон проектирования интерфейса — MVC (Model View Control). Его часто применяют в разработке бизнес-приложений, он не привязан к конкретному языку программирования. Шаблон состоит из трёх компонентов: модель данных (Model), пользовательский интерфейс (View), управляющая логика (Control). Реализация каждого из компонентов делается отдельно, а их сочетание позволяет пользователю работать с данными через интерфейс. Такая модель реализации позволяет не только разделять работу по проектированию собственно интерфейса (View), управляющей логики (Control) и функциональной логики приложения (Model), но и создавать различные сочетания этих трёх компонентов.

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

Поясню: да, паттерны — объективная реальность разработки, однако «забивать» ими голову в самом начале своего пути в программировании пойдёт только во вред. Вместо того, чтобы доходить до базовых уровней понимания своей работы, новичок может заучить определённый паттерн и далее пытаться встраивать его в проект при любом удобном случае. Не вникать в суть вещей, а выискивать (подчас даже искусственно создавать) ситуацию, когда по его, новичка, мнению, было бы уместно использовать тот или иной паттерн.

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

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

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

Мы делаем сайты на Битрикс, поэтому расскажу про PHP-программистов и frontend-программистов.

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

Например, почти все веб-программисты так или иначе работали с библиотекой jQuery — а это уже целый набор шаблонов:

• Компоновщик (Composite) — работа с множеством объектов как с одним объектом $('.button').hide();
• Адаптер (Adapter) — работа со свойствами и событиями так, будто все браузеры одинаковые $(".container").css({opacity: .5});
• Фасад (Facade) — создание более простых интерфейсов над сложными $.post() = $.ajax({type: "POST"});
• Наблюдатель (Observer) — в принципе вся система событий в JS $(document).on('somethingHappened');
• Итератор (Iterator) — перебор всех объектов $.each(...);
• Заместитель (Proxy) — подмена одного объекта другим с аналогичным поведением. В jQuery — передача контекста this внутрь функции $("button").on("click", function () {$(this).addClass("active");}); внутри реализовано через $.proxy();
• Строитель (Builder) — Создание нескольких объектов одной командой $('<li><a href="#">Link</a></ul>').

В Битрикс программист так же регулярно применяет несколько шаблонов:

• Одиночка (Singleton) — это классы CMain и CDatabase;
• Наблюдатель (Observer) — Система событий в Битрикс — класс EventManager (который ко всему ещё и Одиночка);
• MVC — Модель-представление-контроллер — Компоненты 2.0 в Битрикс;
• Адаптер (Adapter) — абстрагируемся от конкретной базы данных через класс CDatabase;
• ORM — Работа с объектами вместо работы с базой напрямую;
• Пространство имён (Namespace) — уменьшает кол-во глобальных переменных и предотвращает конфликты имён классов, функций и переменных.

У тех, кто пишет на React, тоже целый набор шаблонов:

• Передача свойств вниз по дереву компонентов;
• условный рендеринг;
• деструктурирование свойств;
• шаблон «провайдер»;
• компоненты высшего порядка и т.д.

Есть очень хороший ресурс для начала изучения шаблонов проектирования. Тут 22 шаблона с иллюстрациями и примерами.

Для лучшего понимания шаблонов проектирования полезно освежить в голове принципы Объектно-ориентированного программирования (ООП), а также копнуть в сторону функционального программирования.

Итак, какие шаблоны проектирования нужно знать и действительно ли нужно?

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

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

Кроме того, для решения задачи знания подходящих шаблонов проектирования недостаточно. Не помешает изучить анти-шаблоны — подходы, которые приводят к плохим результатам.

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

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

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Это свод принципов, призванный помочь разработчикам писать чистый, хорошо структурированный и легко читаемый код. Программисты представляют себе по-разному «правильный» подход к написанию приложений — это больше зависит от их личного опыта и предпочтений. Однако идеи SOLID широко распространены среди разработчиков ПО, более того, они были интегрированы в Agile.

Расшифровка аббревиатуры:

• Single Responsibility Principle (SRP) — принцип единственной ответственности. Каждый класс выполняет только свои задачи.
• Open-Closed Principle (OCP) — принцип открытости/закрытости — программные сущности (классы, модули, функции и пр.) должны быть открыты для расширения, но закрыты для модификации.
• Liskov Substitution Principle (LSP) — принцип подстановки Барбары Лисков гласит: «наследующий класс должен дополнять, а не изменять базовый».
• Interface Segregation Principle (ISP) — принцип разделения интерфейса: «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения».
• Dependency Inversion Principle (DIP) — принцип инверсии зависимостей: «абстракции не должны зависеть от деталей — детали должны зависеть от абстракций».

В данном материале мы рассмотрим SRP — принцип единственной ответственности.

Немного предыстории

Роберт Мартин изначально ввёл термин в качестве составляющей своего труда «Принципы объектно-ориентированного проектирования». В основу SRP Мартина легла закономерность связности, описанная Томом Демарко и Мейлиром Пейдж-Джонсоном.

Кроме того, в разработке ПО есть два схожих понятия – инкапсуляция и сокрытие информации. SRP включает в себя также и эти два (или одно) понятия от Дэвида Парнаса, который обозначил их примерно так: «декомпозиция системы на модули не должна основываться на анализе блок-схем или потоков исполнения. Вместо этого, каждый модуль должен содержать внутри некоторое решение (design decision), предоставляя минимальное количество информации о нём своим клиентам».

Суть SRP

Суть SRP в одном предложении: «соберите всё, изменяемое по одной и той же причине, но разделите изменяемое по разным причинам».

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

«Божественный объект»

Лучший способ изучить SRP — увидеть его в действии. Ниже показан пример программы на Ruby, не соответствующей принципу единственной ответственности. Код описывает поведение и атрибуты космической станции. Посмотрите на него и попробуйте определить:

• обязанности объектов, конкретизированные в классе SpaceStation;
• виды лиц, которые могут быть заинтересованы в деятельности космической станции.

Видно, что класс SpaceStation имеет несколько «функций» или «задач»:

• работа с сенсорами;
• использование расходных материалов;
• расход топлива;
• использование подруливающих двигателей.

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

• научный работник, управляющий сенсорами;
• специалист по материально-техническому обеспечению;
• лицо, ответственное за запасы топлива;
• пилот.

Программа полностью не соответствует принципам SRP, но в полной мере отражает суть «Божественного объекта» — основного анти-шаблона в объектно-ориентированном программировани. При таком подходе объект хранит слишком большое количество данных и содержит много методов, поэтому его роль становится «божественной» или всеобъемлющей. Вместо того, чтобы общаться друг с другом, объекты обращаются к всеобъемлющему, а так как на нём завязан весь проект (или его большая часть), то его обслуживание усложняется, увеличивая риск поломки существующей функциональности.

Обратимся к примеру с космической станцией. Представьте, если надо добавить медицинский отсек, а из-за этого произойдут какие-нибудь проблемы с топливным. Попробуйте представить, что для того, чтобы шагнуть, вам нужно выгнуть левую руку назад, повернуть голову вправо и нагнуться. Работает? Да. Терпимо? Возможно. А если нужно бежать? А если с вёдрами? То же самое и с проектом — он будет работать, но до определённого момента.

Нарушение SRP может быть выгодно в начале проекта, но это лишь краткосрочно. С ростом проекта будут увеличиваться финансовые и временны́е ресурсы для исправления существующих проблем. Влияющие друг на друга участки кода, его громоздкость и нечитаемость — главные проблемы, о которых надо подумать при игнорировании SRP.

Разбивка по обязанностям

Выше были определены 4 функции станции, которые управлялись классом SpaceStation. Они и будут отправной точкой рефакторинга кода. Теперь программа чуть больше соответствует SRP.

Теперь класс SpaceStation скорее служит контейнером, внутри которого выполняются операции для подчинённых частей:

• набора сенсоров;
• системы подачи расходных материалов;
• топливного бака;
• подруливающих двигателей.

Каждая из частей принимает форму поля, задаваемого при инициализации космической станции. Для каждой переменной есть соответствующий класс:

• Sensors (сенсоры);
• SupplyHold (поставки расходных материалов);
• FuelTank (топливный бак);
• Thrusters (подруливающие двигатели).

В этой версии кода есть некоторые важные отличия от предыдущей, а именно: отдельные элементы функциональности не только инкапсулированы в собственные классы, но и организованы таким образом, чтобы быть предсказуемыми и последовательными. Идея заключается в группировке сходных по функциональности элементов, для следования принципу связности, и в изолировании данных таким образом, чтобы они были доступны только для соответствующих субъектов. Если понадобится изменить принцип работы системы поставки с хэш-структуры на массив, то это легко можно сделать, используя класс SupplyHold. Таким образом другие модули не будут затронуты. Причём класс SpaceStation даже не будет догадываться о действиях, производимых в модулях.

Заметьте, что сейчас в коде выше есть методы report_supplies и report_fuel, содержащиеся в классах SupplyHold и FuelTank. Что, если с Земли попросят изменить механизм загрузки отчётов? Придётся редактировать оба предыдущих класса. А если руководство решит изменить технологию доставки топлива и расходных материалов? Кажется, придётся повторно изменять те же классы. Похоже на нарушение SRP. Надо бы исправить.

В последней версии программы обязанности «модулей» были разбиты на два дочерних класса FuelReporter и SupplyReporter, объединённых под родительским классом Reporter. Далее были добавлены экземплярные переменные к классу SpaceStation, чтобы запустить соответствующий Reporter. Если руководству с Земли понадобится ещё что-то изменить, то можно внести правки в подклассы, не влияя на работу объектов (классов), о которых они докладывают.

Конечно, до сих пор есть некоторая связь между разными классами. Например, SupplyReporter зависит от SupplyHold, так же зависим и FuelReporter от FuelTank. Кроме того, подруливающие двигатели тоже должны быть связаны с топливным баком. Все эти связи кажутся довольно логичными и на этом уровне уже можно изменять код одного объекта, не влияя на другой (либо влияя незначительно).

В итоге код программы стал более «модульным» и обязанности объектов ясным образом были обозначены. Вероятность «поломки» кода значительно уменьшена, а работать с ним стало приятнее, так как «божественный объект» (которым был весь код до второй редакции) был преобразован в SRP-код, если так можно выразиться.

Шаблоны проектирования — это руководства по решению повторяющихся проблем. Это не классы, пакеты или библиотеки, которые можно было бы подключить к вашему приложению и сидеть в ожидании чуда. Они скорее являются методиками, как решать определенные проблемы в определенных ситуациях.

Википедия описывает их следующим образом:

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

Будьте осторожны

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

Также заметьте, что примеры ниже написаны на PHP 7. Но это не должно вас останавливать, ведь принципы остаются такими же.

Типы шаблонов

Шаблоны бывают следующих трех видов:

1. Порождающие.
2. Структурные.
3. Поведенческие — о них мы рассказываем в этой статье.

Простыми словами: Поведенческие шаблоны связаны с распределением обязанностей между объектами. Их отличие от структурных шаблонов заключается в том, что они не просто описывают структуру, но также описывают шаблоны для передачи сообщений / связи между ними. Или, другими словами, они помогают ответить на вопрос «Как запустить поведение в программном компоненте?»

Википедия гласит:

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

Поведенческие шаблоны:

• цепочка обязанностей (Chain of Responsibility);
• команда (Command);
• итератор (Iterator);
• посредник (Mediator);
• хранитель (Memento);
• наблюдатель (Observer);
• посетитель (Visitor);
• стратегия (Strategy);
• состояние (State);
• шаблонный метод (Template Method).

Цепочка обязанностей (Chain of Responsibility)

Википедия гласит:

Цепочка обязанностей— поведенческий шаблон проектирования предназначенный для организации всистеме уровней ответственности.

Пример из жизни: например, у вас есть три платежных метода (A, B и C), настроенных на вашем банковском счёте. На каждом лежит разное количество денег. На A есть 100 долларов, на B есть 300 долларов и на C — 1000 долларов. Предпочтение отдается в следующем порядке: A, B и C. Вы пытаетесь заказать что-то, что стоит 210 долларов. Используя цепочку обязанностей, первым на возможность оплаты будет проверен метод А, и в случае успеха пройдет оплата и цепь разорвется. Если нет, то запрос перейдет к методу B для аналогичной проверки. Здесь A, B и C — это звенья цепи, а все явление — цепочка обязанностей.

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

Обратимся к коду. Приведем пример с банковскими счетами. Изначально у нас есть базовый Account с логикой для соединения счетов цепью и некоторые счета:

Теперь приготовим цепь, используя объявленные выше звенья (например, Bank, Paypal, Bitcoin):

Примеры на Java и Python.

Команда (Command)

Википедия гласит:

Команда— поведенческий шаблон проектирования, используемый при объектно-ориентированном программировании, представляющий действие. Объект команды заключает всебе само действие иего параметры.

Пример из жизни: Типичный пример: вы заказываете еду в ресторане. Вы (т.е. Client) просите официанта (например, Invoker) принести еду (то есть Command), а официант просто переправляет запрос шеф-повару (то есть Receiver), который знает, что и как готовить. Другим примером может быть то, что вы (Client) включаете (Command) телевизор (Receiver) с помощью пульта дистанционного управления (Invoker).

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

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

Затем у нас есть интерфейс Command, который каждая команда должна реализовывать, и затем у нас будет набор команд:

Затем у нас есть Invoker, с которым клиент будет взаимодействовать для обработки любых команд:

Наконец, мы можем увидеть, как использовать нашего клиента:

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

Примеры на Java и Python.

Итератор (Iterator)

Википедия гласит:

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

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

Простыми словами: Представляет способ доступа к элементам объекта без показа базового представления.

Обратимся к примерам в коде. В PHP очень просто реализовать это, используя SPL (Standard PHP Library). Приводя наш пример с радиостанциями, изначально у нас есть Radiostation:

Затем у нас есть итератор:

Пример использования:

Примеры на Java и Python.

Посредник (Mediator)

Википедия гласит:

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

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

Простыми словами: Шаблон посредник подразумевает добавление стороннего объекта (посредника) для управления взаимодействием между двумя объектами (коллегами). Шаблон помогает уменьшить связанность (coupling) классов, общающихся друг с другом, ведь теперь они не должны знать о реализациях своих собеседников.

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

Изначально у нас есть посредник ChatRoomMediator:

Затем у нас есть наши User (коллеги):

Пример использования:

Примеры на Java и Python.

Хранитель (Memento)

Википедия гласит:

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

Пример из жизни: В качестве примера можно привести калькулятор (создатель), у которого любая последняя выполненная операция сохраняется в памяти (хранитель), чтобы вы могли снова вызвать её с помощью каких-то кнопок (опекун).

Простыми словами: Шаблон хранитель фиксирует и хранит текущее состояние объекта, чтобы оно легко восстанавливалось.

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

Изначально у нас есть наш объект EditorMemento, который может содержать состояние редактора:

Затем у нас есть наш Editor (создатель), который будет использовать объект хранитель:

Пример использования:

Примеры на Java и Python.

Наблюдатель (Observer)

Википедия гласит:

Наблюдатель — поведенческий шаблон проектирования, также известен как «подчинённые» (Dependents). Создает механизм укласса, который позволяет получать экземпляру объекта этого класса оповещения отдругих объектов обизменении ихсостояния, тем самым наблюдая заними.

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

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

Обратимся к коду. Приводя наш пример. Изначально у нас есть JobSeeker, которые ищут работы JobPost и должны быть уведомлены о её появлении:

Затем мы делаем публикации JobPostings на которые соискатели могут подписываться:

Пример использования:

Примеры на Java и Python.

Посетитель (Visitor)

Википедия гласит:

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

Пример из жизни: Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон посетитель помогает добавлять места для посещения.

Простыми словами: Шаблон посетитель позволяет добавлять будущие операции для объектов без их модифицирования.

Перейдем к примерам в коде. Возьмём зоопарк: у нас есть несколько видов Animal, и нам нужно послушать издаваемые ими звуки.

Затем у нас есть реализация для животных:

Давайте реализуем посетителя:

Пример использования:

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

Пример использования:

Примеры на Java и Python.

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

Википедия гласит:

Стратегия — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого изних иобеспечения ихвзаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо отобъектов-клиентов, которые его используют.

Пример из жизни: Возьмём пример с пузырьковой сортировкой. Мы её реализовали, но с ростом объёмов данных сортировка работа стала выполняться очень медленно. Тогда мы сделали быструю сортировку. Алгоритм работает быстрее на больших объёмах, но на маленьких он очень медленный. Тогда мы реализовали стратегию, при которой для маленьких объёмов данных используется пузырьковая сортировка, а для больших объёмов — быстрая.

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

Перейдем к коду. Возьмем наш пример. Изначально у нас есть наша SortStrategy и разные её реализации:

И у нас есть Sorter, который собирается использовать какую-то стратегию:

Пример использования:

Примеры на Java и Python.

Состояние (State)

Википедия гласит:

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

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

Простыми словами: Шаблон позволяет менять поведение класса при изменении состояния.

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

Изначально у нас есть интерфейс WritingState и несколько его реализаций:

Затем TextEditor:

Пример использования:

Примеры на Java и Python.

Паттерн состояние применяется в проектировании распределённых сиситем, наряду с другими паттернами.

Шаблонный метод (Template Method)

Википедия гласит:

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

Пример из жизни: Допустим, вы собрались строить дома. Этапы будут такими:

1. Подготовка фундамента.
2. Возведение стен.
3. Настил крыши.
4. Настил перекрытий.

Порядок этапов никогда не меняется. Вы не настелите крышу до возведения стен и т. д. Но каждый этап модифицируется: стены, например, можно возвести из дерева, кирпича или газобетона.

Простыми словами: Шаблонный метод определяет каркас выполнения определённого алгоритма, но реализацию самих этапов делегирует дочерним классам.

Обратимся к коду. Допустим, у нас есть программный инструмент, позволяющий тестировать, проводить контроль качества кода, выполнять сборку, генерировать отчёты сборки (отчёты о покрытии кода, о качестве кода и т. д.), а также развёртывать приложение на тестовом сервере.

Изначально у нас есть наш Builder, который описывает скелет для построения алгоритма:

Затем у нас есть его реализации:

Пример использования:

Примеры на Java и Python.

Шаблоны проектирования — это руководства по решению повторяющихся проблем. Это не классы, пакеты или библиотеки, которые можно было бы подключить к вашему приложению и сидеть в ожидании чуда. Они скорее являются методиками решения определенных проблем в определенных ситуациях.

Википедия описывает их следующим образом:

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

Будьте осторожны

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

Также заметьте, что примеры ниже написаны на PHP 7. Но это не должно вас останавливать, ведь принципы остаются такими же.

Типы шаблонов

Шаблоны бывают следующих трех видов:

1. Порождающие.
2. Структурные — о них мы рассказываем в этой статье.
3. Поведенческие.

Простыми словами: Структурные шаблоны в основном связаны с композицией объектов, другими словами, с тем, как сущности могут использовать друг друга. Ещё одним объяснением было бы то, что они помогают ответить на вопрос «Как создать программный компонент?».

Википедия гласит:

Структурные шаблоны — шаблоны проектирования, вкоторых рассматривается вопрос отом, как изклассов иобъектов образуются более крупные структуры.

Список структурных шаблонов проектирования:

• адаптер (Adapter);
• мост (Bridge);
• компоновщик (Composite);
• декоратор (Decorator);
• фасад (Facade);
• приспособленец (Flyweight);
• заместитель (Proxy).

Адаптер (Adapter)

Википедия гласит:

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

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

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

Обратимся к коду. Представим игру, в которой охотник охотится на львов.

Изначально у нас есть интерфейс Lion, который реализует всех львов:

И Hunter охотится на любую реализацию интерфейса Lion:

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

Способ применения:

Примеры на Java и Python.

Мост (Bridge)

Википедия гласит:

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

Пример из жизни: Представим, что у вас есть сайт с разными страницами, и вам надо разрешить пользователям менять их тему. Что вы будете делать? Создавать множественные копии каждой страницы для каждой темы или просто отдельную тему, которую пользователь сможет выбрать сам? Шаблон мост позволяет вам сделать второе.

Простыми словами: Шаблон мост — это предпочтение композиции над наследованием. Детали реализации передаются из одной иерархии в другой объект с отдельной иерархией.

Обратимся к примеру в коде. Возьмем пример с нашими страницами. У нас есть иерархия WebPage:

И отдельная иерархия Theme:

Применение в коде:

Примеры на Java и Python.

Компоновщик (Composite)

Википедия гласит:

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

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

Простыми словами: Шаблон компоновщик позволяет клиентам работать с индивидуальными объектами в едином стиле.

Обратимся к коду. Возьмем наш пример с рабочими. У нас есть Employee разных типов:

Теперь у нас есть TaskManager:

Способ применения:

Примеры на Java и Python.

Декоратор (Decorator)

Википедия гласит:

Декоратор — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения кобъекту. Шаблон декоратор предоставляет гибкую альтернативу практике создания подклассов сцелью расширения функциональности.

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

Простыми словами: Шаблон декоратор позволяет вам динамически изменять поведение объекта во время работы, оборачивая их в объект класса декоратора.

Перейдем к коду. Возьмем пример с кофе. Изначально у нас есть простой Coffee и реализующий его интерфейс:

Мы хотим сделать код расширяемым, чтобы при необходимости можно было изменять его. Давайте сделаем некоторые дополнения (декораторы):

А теперь приготовим Coffee:

Примеры на Java и Python.

Фасад (Facade)

Википедия гласит:

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

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

Простыми словами: Шаблон фасад предоставляет упрощенный интерфейс для сложной системы.

Перейдем к примерам в коде. Возьмем пример с компьютером. Изначально у нас есть класс Computer:

Затем у нас есть фасад:

Пример использования:

Примеры на Java и Python.

Приспособленец (Flyweight)

Википедия гласит:

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

Пример из жизни: Вы когда-нибудь заказывали чай в уличном ларьке? Там зачастуют готовят не одну чашку, которую вы заказали, а гораздо большую емкость. Это делается для того, чтобы экономить ресурсы (газ/электричество). Газ/электричество в этом примере и являются приспособленцами, ресурсы которых делятся (sharing).

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

Перейдем к примерам в коде. Возьмем наш пример с чаем. Изначально у нас есть различные виды Tea и TeaMaker:

Теперь у нас есть TeaShop, который принимает заказы и выполняет их:

Пример использования:

Примеры на Java и Python.

Заместитель (Proxy)

Википедия гласит:

Заместитель — структурный шаблон проектирования, который предоставляет объект, который контролирует доступ кдругому объекту, перехватывая все вызовы (выполняет функцию контейнера).

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

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

Перейдем к коду. Возьмем наш пример с безопасностью. Сначала у нас есть интерфейс Door и его реализация:

Затем у нас есть заместитель Security для защиты любых наших дверей:

Пример использования:

Другим примером будет реализация маппинга данных. Например, недавно я создал ODM (Object Data Mapper) для MongoDB, используя этот шаблон, где я написал заместитель вокруг классов mongo и использовал магический метод __call(). Все вызовы методов были замещены оригинальным классом mongo, и полученный результат возвращался без изменений, но в случае find или findOne данные сопоставлялись необходимому классу, и возвращались в объект вместо Cursor.

Примеры на Java и Python.

Шаблоны проектирования — это руководства по решению повторяющихся проблем. Это не классы, пакеты или библиотеки, которые можно было бы подключить к вашему приложению и сидеть в ожидании чуда. Они скорее являются методиками, как решать определенные проблемы в определенных ситуациях.

Википедия описывает их следующим образом:

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

Ключевые выводы:
— Порождающие шаблоны решают проблемы создания объектов: от простой фабрики до сложного строителя
— Simple Factory и Factory Method делегируют создание объектов, но на разных уровнях абстракции
— Abstract Factory группирует связанные фабрики в единый интерфейс
— Builder спасает от телескопического конструктора при сложной конфигурации объекта
— Prototype клонирует существующие объекты вместо создания с нуля
— Singleton гарантирует единственный экземпляр класса, но считается антипаттерном при злоупотреблении

Будьте осторожны

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

Также заметьте, что примеры ниже написаны на PHP 7. Но это не должно вас останавливать, ведь принципы остаются такими же.

Типы шаблонов

Шаблоны бывают следующих трех видов:

1. Порождающие.
2. Структурные.
3. Поведенческие.

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

Википедия гласит:

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

Существуют следующие порождающие шаблоны:

• простая фабрика (Simple Factory);
• фабричный метод (Factory Method);
• абстрактная фабрика (Abstract Factory);
• строитель (Builder);
• прототип (Prototype);
• одиночка (Singleton).

Простая фабрика (Simple Factory)

Википедия гласит:

Вобъектно-ориентированном программировании (ООП), фабрика— это объект для создания других объектов. Формально фабрика— это функция или метод, который возвращает объекты изменяющегося прототипа или класса изнекоторого вызова метода, который считается «новым».

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

Простыми словами: Простая фабрика генерирует экземпляр для клиента, не раскрывая никакой логики.

Перейдем к коду. У нас есть интерфейс Door и его реализация:

Затем у нас есть наша DoorFactory, которая делает дверь и возвращает её:

И затем мы можем использовать всё это:

Когда использовать: Когда создание объекта — это не просто несколько присвоений, а какая-то логика, тогда имеет смысл создать отдельную фабрику вместо повторения одного и того же кода повсюду.

Пример на Java.

Фабричный метод (Factory Method)

Википедия гласит:

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

Пример из жизни: Рассмотрим пример с менеджером по найму. Невозможно одному человеку провести собеседования со всеми кандидатами на все вакансии. В зависимости от вакансии он должен распределить этапы собеседования между разными людьми.

Простыми словами: Менеджер предоставляет способ делегирования логики создания экземпляра дочерним классам.

Перейдём к коду. Рассмотрим приведенный выше пример про HR-менеджера. Изначально у нас есть интерфейс Interviewer и несколько реализаций для него:

Теперь создадим нашего HiringManager:

И теперь любой дочерний класс может расширять его и предоставлять необходимого интервьюера:

Пример использования:

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

Примеры на Java и Python.

Абстрактная фабрика (Abstract Factory)

Википедия гласит:

Абстрактная фабрика — порождающий шаблон проектирования, предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, неспецифицируя ихконкретных классов. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса онможет создавать окна икнопки). Затем пишутся классы, реализующие этот интерфейс.

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

Простыми словами: Фабрика фабрик. Фабрика, которая группирует индивидуальные, но связанные/зависимые фабрики без указания их конкретных классов.

Обратимся к коду. Используем пример про двери. Сначала у нас есть интерфейс Door и несколько его реализаций:

Затем у нас есть несколько DoorFittingExpert для каждого типа дверей:

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

Пример использования:

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

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

Примеры на Java и Python.

Строитель (Builder)

Википедия гласит:

Строитель — порождающий шаблон проектирования, который предоставляет способ создания составного объекта. Предназначен для решения проблемы антипаттерна «Телескопический конструктор».

Пример из жизни: Представьте, что вы пришли в McDonalds и заказали конкретный продукт, например, БигМак, и вам готовят его без лишних вопросов. Это пример простой фабрики. Но есть случаи, когда логика создания может включать в себя больше шагов. Например, вы хотите индивидуальный сэндвич в Subway: у вас есть несколько вариантов того, как он будет сделан. Какой хлеб вы хотите? Какие соусы использовать? Какой сыр? В таких случаях на помощь приходит шаблон «Строитель».

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

Давайте я покажу на примере, что такое «Телескопический конструктор». Когда-то мы все видели конструктор вроде такого:

Как вы можете заметить, количество параметров конструктора может резко увеличиться, и станет сложно понимать расположение параметров. Кроме того, этот список параметров будет продолжать расти, если вы захотите добавить новые варианты. Это и есть «Телескопический конструктор».

Перейдем к примеру в коде. Адекватной альтернативой будет использование шаблона «Строитель». Сначала у нас есть Burger, который мы хотим создать:

Затем мы берём «Строителя»:

Пример использования:

Когда использовать: Когда может быть несколько видов объекта и надо избежать «телескопического конструктора». Главное отличие от «фабрики» — это то, что она используется, когда создание занимает один шаг, а «строитель» применяется при множестве шагов.

Примеры на Java и Python.

Прототип (Prototype)

Википедия гласит:

Задаёт виды создаваемых объектов спомощью экземпляра-прототипа исоздаёт новые объекты путём копирования этого прототипа. Онпозволяет уйти отреализации ипозволяет следовать принципу «программирование через интерфейсы». Вкачестве возвращающего типа указывается интерфейс/ абстрактный класс навершине иерархии, аклассы-наследники могут подставить туда наследника, реализующего этот тип.

Пример из жизни: Помните Долли? Овечка, которая была клонирована. Не будем углубляться, главное — это то, что здесь все вращается вокруг клонирования.

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

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

Обратимся к коду. В PHP это может быть легко реализовано с использованием clone:

Затем он может быть клонирован следующим образом:

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

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

Примеры на Java и Python.

Одиночка (Singleton)

Википедия гласит:

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

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

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

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

Прим. перев. Подробнее о подводных камнях шаблона одиночка читайте в нашей статье.

Перейдем к коду. Чтобы создать одиночку, сделайте конструктор приватным, отключите клонирование и расширение и создайте статическую переменную для хранения экземпляра:

Пример использования:

Пример на Java.

Часто задаваемые вопросы

Чем Simple Factory отличается от Factory Method?
Simple Factory — это обычный класс с методом создания объектов, он не использует наследование. Factory Method определяет интерфейс создания в родительском классе и делегирует выбор конкретного класса наследникам. Simple Factory — одна точка создания, Factory Method — распределённая через полиморфизм.

Когда выбрать Builder вместо Factory?
Используйте Builder, когда создание объекта требует нескольких шагов или конфигурационных параметров (телескопический конструктор). Factory подходит, когда создание занимает один шаг, а выбор конкретного класса зависит от входных данных.

Почему Singleton считается антипаттерном?
Singleton вводит глобальное состояние, затрудняет юнит-тестирование (сложно подменить зависимость), создаёт неявные связи между компонентами и нарушает принцип единственной ответственности. Используйте его только когда действительно нужен единственный экземпляр — например, для пула соединений или конфигурации.

Можно ли комбинировать порождающие шаблоны?
Да, это распространённая практика. Например, Abstract Factory может использовать Factory Method для создания конкретных продуктов, а Builder может применять Prototype для клонирования шаблонного объекта вместо создания с нуля.

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

Event Emitter можно перевести как “транслятор” или “эмиттер” событий. Звучит как название штуки, умеющей генерировать событие, которое может “услышать” кто угодно.

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

Event Emitter — это шаблон, который можно реализовать разными способами. Основная идея в том, чтобы грамотно создать основу для управления событиями и реализовать возможность любым элементам “подписаться” на него (и быть в курсе происходящего). С другими шаблонами проектирования вы можете познакомиться в нашей статье.

Уже интересно, как такая магия может работать? Итак, мы хотим добиться кода, который затем можно будет использовать так:

Начнем.

Реализация

Как видите, конструктор нашего класса будет инициализировать поле events, пока что делая его пустым объектом. Задача этого поля — хранить события, “подписавшиеся” на нас (то есть в нем будут храниться функции).

Метод subscribe:

Этот метод принимает в качестве аргументов название события (например, event:name-changed, как в нашем примере) и функцию, которая будет вызываться, когда будет инициироваться транслируемое событие.

Одна из ключевых особенностей функций в JavaScript состоит в том, что функции — это этакие “объекты первого класса”, то есть мы можем передать функцию в качестве параметра другой функции, как в методе subscribe().

Метод emit:

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

Собственно, с реализацией паттерна мы закончили. Но пока остается одна проблема: нам нужно будет “отписать” функции, которые нам больше не нужны. Не сделаем этого — столкнемся с утечкой памяти.

Давайте решим эту проблему. Пусть метод subscribe() возвращает функцию unsubscribe(), которую позже можно будет использовать, чтобы отписаться от события.

Как мы помним, в JavaScript особенные функции — их легко можно вернуть из другой функции. Теперь метод subscribe() можно использовать следующим образом:

Вызывая сохраненную в переменной функцию unsubscribe(), мы отписываемся от события.

Вот и все. Пока-пока, утечки памяти!

Вот тут можно попробовать весь получившийся код в действии.

Определение паттерна

Само описание паттерна достаточно простое — класс должен гарантированно иметь лишь один объект, и к этому объекту должен быть предоставлен глобальный доступ. Скорее всего, причина его популярности как раз и кроется в этой простоте — всего лишь один класс, ничего сложного. Это, наверное, самый простой для изучения и реализации паттерн. Если вы встретите человека, который только что узнал о существовании паттернов проектирования, можете быть уверены, что он уже знает про Singleton. Проблема заключается в том, что когда из инструментов у вас есть только молоток, всё вокруг выглядит как гвозди. Из-за этого “Одиночкой” часто злоупотребляют.

Простейшая реализация

Как уже говорилось выше, в этом нет ничего сложного:

• Сделайте конструктор класса приватным, чтобы не было возможности создать экземпляр класса извне.
• Храните экземпляр класса в private static поле.
• Предоставьте метод, который будет давать доступ к этому объекту.

Принцип единственной обязанности

В объектно-ориентированном программировании существует правило хорошего тона — “Принцип едиственной обязанности” (Single Responsibility Principle, первая буква в аббревиатуре SOLID). Согласно этому правилу, каждый класс должен отвечать лишь за один какой-то аспект. Совершенно очевидно, что любой Singleton-класс отвечает сразу за две вещи: за то, что класс имеет лишь один объект, и за реализацию того, для чего этот класс вообще был создан.

Принцип единственной обязанности был создан не просто так — если класс отвечает за несколько действий, то, внося изменения в один аспект поведения класса, можно затронуть и другой, что может сильно усложнить разработку. Так же разработку усложняет тот факт, что переиспользование (reusability) класса практически невозможно. Поэтому хорошим шагом было бы, во-первых, вынести отслеживание того, является ли экземпляр класса единственным, из класса куда-либо во вне, а во-вторых, сделать так, чтобы у класса, в зависимости от контекста, появилась возможность перестать быть Singleton’ом, что позволило бы использовать его в разных ситуациях, в зависимости от необходимости (т.е. с одним экземпляром, с неограниченным количество экземпляров, с ограниченным набором экземпляров и так далее).

Тестирование

Один из главных минусов паттерна “Одиночка” — он сильно затрудняет юнит-тестирование. “Одиночка” привносит в программу глобальное состояние, поэтому вы не можете просто взять и изолировать классы, которые полагаются на Singleton. Поэтому, если вы хотите протестировать какой-то класс, то вы обязаны вместе с ним тестировать и Singleton, но это ещё полбеды. Состояние “Одиночки” может меняться, что порождает следующие проблемы:

• Порядок тестов теперь имеет значение;
• Тесты могут иметь нежелательные сторонние эффекты, порождённые Singleton’ом;
• Вы не можете запускать несколько тестов параллельно;
• Несколько вызовов одного и того же теста могут приводить к разным результатам.

На эту тему есть отличный доклад с “Google Tech Talks”:

Скрытые зависимости

Обычно, если классу нужно что-то для работы, это сразу понятно из его методов и конструкторов. Когда очевидно, какие зависимости есть у класса, гораздо проще их предоставить. Более того, в таком случае вы можете использовать вместо реально необходимых зависимостей заглушки для тестирования. Если же класс использует Singleton, это может быть совершенно не очевидно. Всё становится гораздо хуже, если экземпляру класса для работы необходима определённая инициализация (например, вызов метода init(...) или вроде того). Ещё хуже, если у вас существует несколько Singleton’ов, которые должны быть созданы и инициализированы в определённом порядке.

Загрузчик класса

Если говорить о Java, то обеспечение существования лишь одного экземпляра класса, которое так необходимо для Singleton, становится всё сложнее. Проблема в том, что классическая реализация не проверяет, существует ли один экземпляр на JVM, он лишь удостоверяется, что существует один экземпляр на classloader. Если вы пишете небольшое клиентское приложение, в котором используется лишь один classloader, то никаких проблем не возникнет. Однако если вы используете несколько загрузчиков класса или ваше приложение должно работать на сервере (где может быть запущено несколько экземпляров приложения в разных загрузчиках классов), то всё становится очень печально.

Десериализация

Ещё один интересный момент заключается в том, что на самом деле стандартная реализация Singleton не запрещает создавать новые объекты. Она запрещает создавать новые объекты через конструктор. А ведь существуют и другие способы создать экземпляр класса, и один из них — сериализация и десериализация. Полной защиты от намеренного создания второго экземпляра Singleton’а можно добиться только с помощью использования enum’а с единственным состоянием, но это — неоправданное злоупотребление возможностями языка, ведь очевидно, что enum был придуман не для этого.

Потоконебезопасность

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

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

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

Разумеется, можно просто пометить метод как synchronised, и эта проблема исчезнет. Проблема заключается в том, что, сохраняя время на старте программы, мы теперь будем терять его каждый раз при обращении к Singleton’у из-за того, что метод синхронизирован, а это очень дорого, если к экземпляру приходится часто обращаться. А ведь единственный раз, когда свойство synchronised действительно требуется — первое обращение к методу.

Есть два способа решить эту проблему. Первый — пометить как synchronised не весь метод, а только блок, где создаётся объект:

Не забывайте, что это нельзя использовать в версии Java ниже, чем 1.5, потому что там используется иная модель памяти. Также не забудьте пометить поле instance как volatile.

Второй путь — использовать паттерн “Lazy Initialization Holder”. Это решение основано на том, что вложенные классы не инициализируются до первого их использования (как раз то, что нам нужно):

Рефлексия

Мы запрещаем создавать несколько экземпляров класса, помечая конструктор приватным. Тем не менее, используя рефлексию, можно без особого труда изменить видимость конструктора с private на public прямо во время исполнения:

Конечно, если вы используете Singleton только в своём приложении, переживать не о чем. А вот если вы разрабатываете модуль, который затем будет использоваться в сторонних приложениях, то из-за этого могут возникнуть проблемы. Какие именно, зависит от того, что делает ваш “Одиночка” — это могут быть как и риски, связанные с безопасностью, так и просто непредсказуемое поведение модуля.

Заключение

Несмотря на то, что паттерн Singleton очень известный и популярный, у него есть множество серьёзных недостатков. Чем дальше, тем больше этих недостатков выявляется, и оригинальные паттерны из книги GOF “Design Patterns” часто сегодня считаются антипаттернами. Тем не менее, сама идея иметь лишь один объект на класс по-прежнему имеет смысл, но достаточно сложно реализовать ее правильно.

• Первая часть
• Вторая часть
• Третья часть

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

Что такое шаблоны проектирования

Шаблоны проектирования — это проверенные и готовые к использованию решения часто возникающих в повседневном программировании задач. Это не класс и не библиотека, которую можно подключить к проекту, это нечто большее. Шаблон проектирования, подходящий под задачу, реализуется в каждом конкретном случае. Кроме того, он не зависит от языка программирования. Хороший шаблон легко реализуется в большинстве, если не во всех языках, в зависимости от выразительных средств языка. Следует, однако, помнить, что такой шаблон, будучи примененным неправильно или к неподходящей задаче, может принести немало проблем. Тем не менее, правильно примененный шаблон поможет решить задачу легко и просто.

Существует три типа шаблонов:

• структурные;
• порождающие;
• поведенческие.

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

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

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

Зачем нужны шаблоны проектирования

Шаблон проектирования, по своей сути, это продуманное решение той или иной задачи. Если вы столкнулись с известной задачей, почему бы не использовать готовое решение, проверенное опытом?

Пример

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

Просто, не правда ли? Давайте посмотрим поближе на шаблон «Стратегия».

Паттерн проектирования «Стратегия»

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

В примере выше выбор стратегии основан на значении переменной $context, которое было в момент создания объекта. Если значение было "context_for_class_one", программа будет использовать класс class_one. И наоборот.

Где это можно использовать

Представьте, что вы разрабатываете класс, который может создать или обновить запись в базе данных. В обоих случаях входные параметры будут одни и те же (имя, адрес, номер телефона и т. п.), но, в зависимости от ситуации, он будет должен использовать различные функции для обновления и создания записи. Можно каждый раз переписывать условие if/else, а можно создать один метод, который будет принимать контекст:

Обычно шаблон «Стратегия» подразумевает инкапсуляцию алгоритмов в классы, но в данном случае это излишне. Помните, что вы не обязаны следовать шаблону слово в слово. Любые варианты допустимы, если они решают задачу и соответствуют концепции.

Шаблон «Адаптер»

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

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

Как его использовать?

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

Сравните два примера.

Без адаптера:

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

С использованием адаптера:

Мы можем создать класс-обертку Account:

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

Шаблон «Метод-фабрика»

Фабрика — порождающий шаблон, который представляет собой класс с методом для создания различных объектов.

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

Как его использовать?

Фабрика обычно используется для создания различных вариантов базового класса. Допустим, у вас есть класс кнопки — Button — и три варианта — ImageButton, InputButton и FlashButton. С помощью фабрики вы можете создавать различные варианты кнопок в зависимости от ситуации.

Сначала создадим три класса:

Теперь мы можем написать нашу фабрику:

и использовать ее:

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

Шаблон «Декоратор»

Декоратор — это структурный шаблон, который позволяет добавить новое поведение объекту в процессе выполнения программы в зависимости от ситуации.

Цель — в расширении поведения конкретного объекта без необходимости изменять поведение базового класса. Это позволит использовать несколько декораторов одновременно. Этот шаблон — альтернатива наследованию. В отличие от наследования, декоратор добавляет поведение в процессе выполнения программы.

Для реализации декоратора нам понадобится:

1. Унаследовать класс-декоратор от базового.
2. Добавить поле со ссылкой на базовый класс в декоратор.
3. Передать ссылку на декорируемый объект в конструктор декоратора.
4. Перенаправить методы из декоратора на декорируемый объект.
5. Переопределить методы в декораторе, поведение которых необходимо изменить.

Как его использовать?

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

Сначала определимся, какие «декорации» нам нужны:

• Если мы на заглавной странице и вошли в аккаунт, ссылка должна быть в h2-теге.
• Если мы на любой другой странице и вошли в аккаунт, ссылка должна быть подчеркнутой.
• Если мы вошли в аккаунт, ссылка должна быть в strong-теге.

Теперь мы можем написать сами декораторы:

Теперь мы можем использовать их так:

Обратите внимание, как можно использовать несколько декораторов на одном объекте. Все они используют функцию __call для вызова оригинального метода. Если мы войдем в аккаунт и перейдем на заглавную страницу, результат будет такой:

Шаблон «Одиночка»

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

Его можно использовать как точку «координации» для других объектов, поскольку поля «Одиночки» будут одинаковы для всех, кто его вызывает.

Как его использовать?

Если вам необходимо передавать определенный экземпляр из класса в класс, вы можете передавать его каждый раз через конструктор или использовать «Одиночку». Допустим, у вас есть класс Session, который содержит данные о текущей сессии. Поскольку сессия инициализируется только один раз, мы можем реализовать его так:

Теперь мы можем получить доступ к сессии из различных участков кода, даже из других классов. Метод getInstance всегда будет возвращать одну и ту же сессию.

Заключение

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

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