Что такое паттерн (по автору)

Паттерн — это не структура классов и не конкретный код. Паттерн = проблема + способ её решения. Эта заметка собирает фундаментальные тезисы автора о природе паттернов.

Главное определение

«Паттерн — это любая структура классов, которая решает задачу паттерна»

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

Что НЕ есть паттерн

  • Не привязан к языку: «Если решение работает только для одной задачи и не переиспользуется — это не паттерн, это код».
  • Не привязан к стилю: один и тот же паттерн реализуется на классах, прототипах, функциях — это одинаково валидно.
  • Не привязан к ООП: SOLID, GRASP и GoF переносятся в ФП с минимальными изменениями (по автору).
  • Не привязан к синтаксису: «Декоратор как синтаксис ≠ GoF Decorator», хотя решают похожую задачу.

Хронология появления

Согласно автору:

«Применяют сверху вниз: GRASP → SOLID → GoF. А придумывалось снизу вверх: GoF → SOLID → GRASP.»

  1. GoF (1994) — конкретные шаблоны из практики (Гамма, Хелм, Джонсон, Влиссидес).
  2. SOLID (Боб Мартин, ~2000) — обобщение десятков паттернов в 5 принципов.
  3. GRASP (Ларман) — вторая итерация обобщения, более абстрактные принципы над SOLID.

Применять при проектировании: сначала GRASP (общие мазки), потом SOLID, потом GoF (детализация).

Зачем нужны паттерны

  1. Общий язык между разработчиками — экономия времени на коммуникацию.
  2. Не изобретать велосипед — типичные проблемы уже решены.
  3. Тренажёр для моделирования — между «выучил язык» и «выучил фреймворк» лежит моделирование, и его тренируют на паттернах.
  4. Защита от AI-халтуры: AI знает паттерны из книжек, но не понимает когда применять. Без знания паттернов нельзя контролировать AI-генерацию.

Почему путаются паттерны в JS

В динамических языках (особенно JS) паттерны схлопываются по коду:

  • Adapter, Decorator, Proxy, Facade — структурно почти одинаковые
  • Различаются только по интенции (цели, контексту)
  • GoF писалось для C++/Java — там было больше разницы в коде

Решение: смотреть не на код, а на «зачем».

Авторские определения важнее книжных

автор делает свой каталог паттернов с авторскими определениями (не из GoF-книги):

  • Определения GoF местами устарели (1994 год)
  • Слишком пространные для практики
  • Не учитывают JS-специфику

Главное — личное понимание через примеры и тренажёры.

Главные принципы по автору

  • «Паттерн = проблема + способ решения».
  • «Если не переиспользуется — не паттерн».
  • «В JS паттерн можно сделать на классах, прототипах, функциях» — все эквивалентны.
  • «Различать паттерны по интенции, не по коду».
  • «Банда 4 — это структура кода в одном процессе» — не архитектура.
  • «Архитектура начинается там, где паттерны GoF заканчиваются» — Enterprise Patterns, DDD.

🎓 Источники

См. также