Разница между шаблонами и паттернами

Выбор правильного термина – дело непростое. Выбор русскоязычного варианта – еще и неблагодарное. Занимаясь научным редактированием переводов книг по IT-тематике я всегда сталкивался с проблемой выбора правильного русскоязычного варианта. Сложность заключается в отсутствии единого мнения по поводу перевода некоторых важных терминов, что приводит к проблеме выбора «наименьшего зла» между распространенным, но неточным термином и более емким, но никому неизвестным вариантом.

С термином “pattern” тоже была интересная история. Изначально, этот термин был переведен как «шаблон», и в первых книгах начала нулевых использовался в основном этот термин, а спустя некоторое время, все больше стал набирать популярность вариант «паттернов проектирования».

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

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

Шаблон представляет собой образец, по которому создаются одинаковые изделия. Он, как трафарет, может содержать подвижные части, но контекст и количество возможных вариантов на выходе строго ограничено. Строго говоря, понятию «шаблон» соответствует англоязычный термин “template”, а не “pattern”.

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

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

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

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

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

Нельзя взять книгу по паттернам и пытаться впихнуть их в свои проекты. Тем более нельзя обобщать паттерны в виде библиотек. Глупо аргументировать использование паттерна на проекте «толстой умной книжкой». Желание добавить «готовое решение из каталога» не зная контекста его использования должно идти лесом. Все это примеры непонимания понятия паттернов, как явления.

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