Паттерн проектирования — подход к решению какой-то типовой задачи. Ранее мы уже рассмотрели некоторые из них, начиная от разных видов диспетчеризации, заканчивая Стратегией и Фабрикой. Этих паттернов очень много, каждый день придумываются новые, и даже каждый программист имеет какие-то свои паттерны для своих задач.
Паттерны, в общем, не связаны с понятием ООП, но именно в ООП их любят структурировать и описывать. Поэтому эта тема особенно распространена в языках с классовой структурой, например Java, C# или PHP. И большинство этих паттернов сводится к тому, как правильно применять полиморфизм подтипов в разных ситуациях. Вот только некоторые из широко известных, которые опираются на полиморфизм:
- Адаптер
- Стратегия
- Абстрактная фабрика
- Мост
- Композит
- Декоратор
- Посредник
- Цепочка ответственности
- Наблюдатель
- Состояние
- Шаблонный метод
- Посетитель
Некоторые из них связаны с абстракцией и имеют внутреннее состояние, другие — обычные функции, упакованные в классы только ради полиморфизма (но могли бы быть реализованы и обычными функциями, которые диспетчеризуются разными способами).
В мире ООП паттернов, их основным источником считается книга — Приемы объектно-ориентированного проектирования. Паттерны проектирования. В ней действительно описано много полезных подходов, но будьте осторожны. Учтите следующие моменты:
- Примеры в книге описаны на языке C++ и имеют более сложную реализацию, чем это нужно в динамических языках.
- Многие паттерны рождаются вследствие ограничений конкретного языка, например паттерн Команда. В JavaScript это естественный способ писать код и для этого не нужны классы.
- Не все паттерны, описанные в этой книге, так уж важны для веб-разработчиков. Вероятность того, что вам придется когда-то иметь дело с абстрактной фабрикой, крайне мала.
- Самих паттернов намного больше, чем указано в этой книге. Паттерны это не догма: все течет, все развивается.
Полиморфизм в паттернах или Паттерн создания Паттернов
Большая часть паттернов, которая связана с полиморфизмом, строится по одному и тому же принципу. Зная его, вы сможете самостоятельно принимать правильные решения, даже не зная про паттерн для данной ситуации. Ключевая идея состоит в том, что берется все множество вариантов поведения и на каждый создается свой собственный класс.
Например, в Стратегии количество классов-стратегий совпадает с количеством разных способов вычисления. Если их будет пять, то придется создать пять классов. По крайней мере в классовых языках. В языках, где предпочитают функции, будет создано пять разных функций и это все равно будет Стратегия.
Антипаттерны
Раз есть паттерны, значит существуют и антипаттерны — это типовые ошибки, которые совершают программисты. Многие из них имеют вполне конкретные, часто шуточные, названия: «паблик морозов» или «божественный объект». Самое удивительное, что подходы, считавшиеся раньше паттернами, иногда перетекают в раздел антипаттернов. Самый яркий пример это паттерн «Одиночка (Singleton)» — объект, который может существовать только в единственном экземпляре. Как показала жизнь, это плохо почти всегда. Кроме того, код с синглтонами крайне сложно тестировать.
Обучение паттернам
Новичков, которые начитались статей и наслушались старших товарищей, очень волнует вопрос изучения паттернов. Нужно ли их учить? Сколько их учить? По каким книгам и так далее.
Попробуем разобраться. Как показывает практика, про паттерны все говорят, но мало кто действительно прочитал, понял их и может разумно применять. Причин этому несколько. Во-первых, крайне сложно осознать паттерн, не столкнувшись с реальной проблемой, которую он решает. Во-вторых, настоящее понимание паттернов завязано на те вещи, которые мы разбирали на протяжении всей профессии: именование (оно чертовски важно), менеджмент состояния, побочные эффекты, абстракции, расширяемость, полиморфизм подтипов. Без понимания этих вещей, попытка использовать паттерны почти наверняка превратится в культ карго. Причем из всего списка выше, паттерны, по эффекту оказываемому на код, находятся на последнем месте.
Важно понимать, что паттерны это не причина, а следствие. Остерегайтесь мышления в стиле «вот есть паттерн, как его натянуть на ситуацию». Сначала нужно понять ситуацию, а потом возникнет паттерн. И совершенно нормально, что первые годы разработки (а у кого-то и больше), задачи будут решаться так, как получается. Обучение происходит через ошибки и неправильные решения, этого не надо бояться и избегать. Главное — это последовательное улучшение, а здесь помогут книги и наставники (на работе или в сети). О том, как лучше читать книги, в том числе по паттернам, мы писали в статье.
Дополнительные материалы
- Принцип единственной ответственности
- Вебинар: Что такое паттерны программирования
- Паттерны (Редакция Хекслета)
- Антипаттерны
- Архитектура корпоративных приложений
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.