Шаблоны проектирования в JavaScript

Кубики с буквами, образующие слово «JAVASCRIPT»

Введение в шаблоны проектирования JavaScript

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

Короткое определение: шаблон проектирования — описанный способ организации кода, направленный на решение конкретной проблемы (инкапсуляция, коммуникация между компонентами, создание объектов и т. п.).

Задачи этой статьи:

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

Важно: шаблон сам по себе не гарантирует качества — он инструмент. Применяйте шаблон осознанно.

Шаблон Модуль

Описание: Модуль обеспечивает инкапсуляцию — приватные данные и поведение скрыты в области видимости, а наружу экспортируется упрощённый публичный API. В JavaScript это удобно реализовать через замыкания и модули (IIFE, ES-модули).

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

Преимущества:

контроль публичного API,
уменьшение числа глобальных переменных,
улучшение читаемости и поддерживаемости.

Ограничения:

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

Пример реализации модуля (на чистом JavaScript):

// Шаблон модуля: пример корзины покупок
const ShoppingCartModule = (function () {
  // Приватные данные
  let cartItems = [];

  // Приватная функция подсчёта количества товаров
  function calculateTotalItems() {
    return cartItems.reduce((total, item) => total + item.quantity, 0);
  }

  // Публичный API
  return {
    addItem(item) {
      cartItems.push(item);
    },

    getTotalItems() {
      return calculateTotalItems();
    },

    clearCart() {
      cartItems = [];
    }
  };
})();

// Пример использования
ShoppingCartModule.addItem({ name: 'Product 1', quantity: 2 });
ShoppingCartModule.addItem({ name: 'Product 2', quantity: 1 });

console.log(ShoppingCartModule.getTotalItems()); // 3

ShoppingCartModule.clearCart();
console.log(ShoppingCartModule.getTotalItems()); // 0

Как это работает — пошагово:

Создаётся немедленно вызываемая функция (IIFE), которая создаёт локальную область видимости.
Внутри этой области объявляются приватные переменные и функции (cartItems, calculateTotalItems).
Функция возвращает объект с методами — это публичный интерфейс модуля.
Вне модуля доступен только возвращённый объект; приватные данные недоступны напрямую.

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

Советы по тестированию и поддержке модуля:

Покрывайте тестами публичный API (unit-тесты для addItem/getTotalItems/clearCart).
Если нужно тестировать приватные функции — выделите их в отдельный модуль или экспортируйте только в тестовой среде.
Документируйте ожидания от публичных методов (валидность входных данных, побочные эффекты).

Шаблон Наблюдатель

Описание: Наблюдатель (Observer) создаёт отношение “один ко многим”: объект-субъект оповещает своих подписчиков при изменении состояния. Подписчики реализуют реакцию на событие без прямой связи с внутренним состоянием субъекта.

Когда использовать: при разработке событийных систем, реалтайм-уведомлений, MVC/MVVM-архитектуры и при декуплинге модулей.

Преимущества:

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

Ограничения:

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

Пример простого наблюдателя:

// Простой NotificationSystem
function NotificationSystem() {
  // Список подписчиков
  this.subscribers = [];

  // Подписка
  this.subscribe = function (subscriber) {
    this.subscribers.push(subscriber);
  };

  // Отписка
  this.unsubscribe = function (subscriber) {
    const index = this.subscribers.indexOf(subscriber);
    if (index !== -1) {
      this.subscribers.splice(index, 1);
    }
  };

  // Уведомление всех подписчиков
  this.notify = function (message) {
    this.subscribers.forEach(function (subscriber) {
      try {
        subscriber.receiveNotification(message);
      } catch (err) {
        // Не допускаем, чтобы ошибка одного подписчика прервала уведомление остальных
        console.error('Ошибка в подписчике:', err);
      }
    });
  };
}

// Объект-подписчик
function Subscriber(name) {
  this.receiveNotification = function (message) {
    console.log(name + ' получил уведомление: ' + message);
  };
}

// Пример использования
const notificationSystem = new NotificationSystem();
const subscriber1 = new Subscriber('Подписчик 1');
const subscriber2 = new Subscriber('Подписчик 2');

notificationSystem.subscribe(subscriber1);
notificationSystem.subscribe(subscriber2);

notificationSystem.notify('Новое уведомление!');

Практические рекомендации при использовании Наблюдателя:

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

Когда шаблоны не подходят — примеры ошибок

Чрезмерное применение шаблонов: если задача проста (простая функция преобразования), внедрять шаблон «на всякий случай» не стоит.
Бессмысленная инкапсуляция: скрытие данных, которые должны быть гибко настраиваемыми извне, усложняет расширение.
Слишком подробный публичный API: множество методов делает модуль трудным для тестирования и поддержки.

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

Как выбирать шаблон: мини-методология

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

Чеклист по ролям

Разработчик:

Есть ли чёткий публичный API?
Есть ли покрытие unit-тестами для публичных методов?
Нет ли утечек приватного состояния во внешнюю область видимости?

Код-ревьюер:

Соответствует ли применение шаблона требованиям проблемы?
Содержит ли код обработку ошибок и границы ответственности?
Документированы ли побочные эффекты?

Архитектор:

Совместим ли выбранный шаблон с общей архитектурой?
Не приводит ли он к чрезмерной связности?
Есть ли стратегия изменения API и миграции старых версий?

SOP: Быстрый план внедрения шаблона

Оцените необходимость: подтверждённый сценарий использования и тесты.
Спроектируйте публичный API на словах (2–6 методов/свойств).
Напишите минимальную реализацию и тесты для публичных методов.
Добавьте логирование и обработку ошибок.
Проведите код-ревью, по возможности провалидируйте производительность.
Документируйте и публикуйте границы использования.

Критерии приёмки

Все публичные методы покрыты unit-тестами.
Изменение приватного состояния невозможно извне (проверка через интеграционные тесты).
Поведение при ошибках задокументировано и предсказуемо.

Decision flowchart: Как выбрать между Модулем и Наблюдателем

flowchart TD
  A[Есть ли состояние, которое нужно скрыть?] -->|Да| B[Рассмотрите Модуль]
  A -->|Нет| C[Нужно ли оповещать несколько подписчиков?]
  C -->|Да| D[Рассмотрите Наблюдатель]
  C -->|Нет| E[Обычная функция / утилита]
  B --> F[Спроектировать публичный API]
  D --> G[Спроектировать модель событий]

Технические тест-кейсы и сценарии приёма

Модуль (корзина):

TC1: после добавления товаров getTotalItems возвращает сумму количеств.
TC2: после clearCart getTotalItems возвращает 0.
TC3: приватные переменные недоступны извне (попытка прямого доступа должна вернуть undefined или throw в тестовой среде).

Наблюдатель (уведомления):

TC1: при notify все подписчики получили сообщение (проверить вызовы мок-объектов).
TC2: ошибка в одном подписчике не прерывает уведомления остальных.
TC3: unsubscribe удаляет подписчика из списка уведомлений.

Безопасность и приватность

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

Факто-бокс: основные паттерны (быстрый обзор)

2 базовых паттерна в этой статье: Модуль, Наблюдатель.
Часто используемые дополнительные паттерны в JavaScript: Синглтон, Фабрика, Декоратор, Прокси, Стратегия.
Рутина: начинайте с 1–2 паттернов и расширяйте набор по мере роста приложения.

Глоссарий в одну строку

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

Альтернативные подходы

ES-модули (import/export): современный способ организации модулей с явным экспортом и импортом.
Событийные шины (EventBus): для приложений с множеством компонентов, где нужны централизованные события.
Реактивные библиотеки (RxJS, MobX): для сложной асинхронной логики и потоков данных.

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

Краткое резюме

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

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

Замечание: соблюдайте безопасность и приватность при работе с персональными данными.