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

Знакомство с паттернами

Любой Frontend-проект начинается с архитектуры. До того, как вы напишете первый useEffect или создадите компонент в Figma, вы строите ментальную модель: какие сущности есть User, ProductCard, CartStore), как они общаются API, Props, Store и кто за что отвечает.

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

Важно! В контексте IT слово «дизайн» означает проектирование системы, а не выбор цвета кнопок. Это инженерная дисциплина.

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

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

Эволюция решения: от хаоса к паттерну

    graph TD
        A[Проблема: Обмен данными между компонентами] --> B{Как решить?}
        B -- "Костыль" --> C[Глобальные переменные window.data]
        C --> D[Сложно отлаживать, конфликты имен]
        B -- "Hardcore" --> E[Prop Drilling на 10 уровней]
        E --> F[Компоненты жестко связаны, сложно менять]
        B -- "Pattern" --> G[Observer / Publish-Subscribe]
        G --> H[Redux / Event Bus: Чистое и масштабируемое решение]
    

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

Объектно-ориентированные паттерны показывают взаимодействия между классами и объектами. Во Frontend мы часто перекладываем эти принципы на компоненты и хуки.

Банда Четырех и Web

Концепция пришла из архитектуры зданий, но в IT она закрепилась в 1994 году с выходом книги "Design Patterns: Elements of Reusable Object-Oriented Software". Авторов (Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес) прозвали Gang of Four (GoF) — «Банда Четырех».

Они описали 23 классических паттерна. Изначально они были написаны для C++ и Smalltalk, затем адаптированы для Java. Сегодня мы, Frontend-разработчики, используем их наследие, но с поправкой на реалии JavaScript, TypeScript и React.

Зачем это Junior Frontend разработчику?

Многие могут сказать: «Зачем мне Singleton, если в JS есть ES-модули?» или «Зачем мне Observer, если есть RxJS?». Ответ прост:

• Когда Senior скажет: «Оберни этот вызов API в Адаптер», вы поймете, что нужно привести формат данных бэкенда к формату, который ждет ваш компонент, а не переписывать весь UI.
• Redux — это паттерн Observer + Command. React Context — это механизм для Dependency Injection. Понимая базу, вы быстрее осваиваете инструменты.
• Это отличает кодера от инженера. Вы перестаете писать «лапша-код» и начинаете строить масштабируемые системы.

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

Глобально они делятся на три группы, как и в оригинальной книге, но с нашими акцентами:

• Порождающие (Creational) — решают проблему создания объектов (или компонентов). Как создать сложный объект, не засоряя код операторами new?
• Структурные (Structural) — отвечают за построение связей. Как собрать сложный UI из простых компонентов или адаптировать старый интерфейс к новому?
• Поведенческие (Behavioral) — управляют коммуникацией. Кто кому отправляет сообщения? Кто отвечает за обработку клика?

UML и Реальность Frontend-а

В классических книгах по паттернам (включая GoF) используется язык UML (Unified Modeling Language). Это стандарт 90-х годов для строгих объектно-ориентированных систем.

Чтобы понять, почему мы (Frontend-разработчики) редко рисуем UML-диаграммы, давайте сравним два подхода к проектированию.

Мир Классического ООП

Здесь разработчик мыслит Иерархиями и Структурой. Главный вопрос: «Как классы связаны друг с другом статически?». Для этого идеально подходит Diagram.

Визуализация Структуры UML Class Diagram

    classDiagram
        direction TB
        %% Описываем классы
        class AbstractPage {
            +render()
            +mount()
        }
        class HomePage {
            -header: HeaderComponent
            +loadData()
        }
        class HeaderComponent {
            +logo: String
        }

        %% Описываем связи правильными стрелками
        AbstractPage <|-- HomePage : Наследование (Is-A)
        HomePage *-- HeaderComponent : Композиция (Part-Of)

        note for HomePage "Жесткая структура. HomePage ЭТО страница. Она СОДЕРЖИТ хедер."
    

Здесь стрелка с треугольником означает Наследование (extends), а закрашенный ромб — Композицию (жесткую зависимость).

---

Мир Modern Frontend

Здесь мы мыслим Потоками Данных и Событиями. Главный вопрос: «Что произойдет с данными, когда пользователь нажмет кнопку?». Статическое наследование нас почти не волнует. Для этого мы используем Flowchart.

Визуализация Потока

    graph TD
        %% Узлы процесса
        User((User Click))
        Handler[Event Handler]
        State[Update Store / State]
        Effect[Side Effect / API Call]
        Render[Re-render Component]
        DOM[Update DOM]

        %% Связи процесса
        User --> Handler
        Handler -- "Dispatch Action" --> State
        State -- "State Changed" --> Render
        Render -- "Diff Calculation" --> DOM

        %% Побочный эффект (например, логгер или аналитика)
        State -.-> Effect
    

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

Основные типы связей в UML

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

    classDiagram
        direction LR

        %% 1. Наследование
        Vehicle <|-- Car : Наследование (Extends)
        note for Car "Треугольник: Car ЯВЛЯЕТСЯ Vehicle"

        %% 2. Композиция
        Modal *-- CloseButton : Композиция (Part-Of)
        note for CloseButton "Закрашенный ромб: Кнопка - часть Модалки.\nУмрет вместе с ней."

        %% 3. Агрегация
        UserList o-- UserCard : Агрегация (Has-A)
        note for UserCard "Пустой ромб: Список содержит Карточки.\nКарточки могут жить отдельно."

        class Vehicle {
            +move()
        }
        class Modal {
            +open()
        }
    

Резюме для Junior Frontend-разработчика:

• В этом курсе мы будем использовать второй тип диаграмм (Flowchart), потому что он лучше отражает работу JavaScript (Event Loop, React Render Cycle).
• Мы избегаем глубокого наследования (треугольные стрелки) в пользу композиции (вкладывания компонентов).
• Паттерны мы будем рассматривать как способы управления потоком данных, а не как нагромождение классов.

Список паттернов по GoF

Ниже представлен список тех самых 23 паттернов. Мы разделили их на три группы:

C — Порождающие (Как создавать объекты/компоненты?)

S — Структурные (Как собирать систему из кирпичиков?)

B — Поведенческие (Как организовать общение и логику?)