Теория: Шаблоны проектирования (Паттерны)

Паттерн проектирования – подход к решению какой-то типовой задачи. Ранее мы уже рассмотрели некоторые из них, начиная от разных видов диспетчеризации, заканчивая Стратегией и Фабрикой. Этих паттернов очень много, каждый день придумываются новые, и даже каждый программист имеет какие-то свои паттерны для своих задач.

Паттерны, в общем, не связаны с понятием ООП, но именно в ООП их любят структурировать и описывать. Поэтому эта тема особенно распространена в языках с классовой структурой, например Java, C# или PHP. И большинство этих паттернов сводится к тому, как правильно применять полиморфизм подтипов в разных ситуациях. Вот только некоторые из широко известных, которые опираются на полиморфизм:

• Адаптер
• Стратегия
• Абстрактная фабрика
• Мост
• Композит
• Декоратор
• Посредник
• Цепочка ответственности
• Наблюдатель
• Состояние
• Шаблонный метод
• Посетитель

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

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

• Примеры в книге описаны на языке C++ и имеют более сложную реализацию, чем это нужно в динамических языках.
• Многие паттерны рождаются вследствие ограничений конкретного языка, например паттерн Команда. В JavaScript это естественный способ писать код и для этого не нужны классы.
• Не все паттерны, описанные в этой книге, так уж важны для веб-разработчиков. Вероятность того, что вам придётся когда-то иметь дело с абстрактной фабрикой, крайне низка.
• Самих паттернов намного больше чем указано в этой книге. Паттерны это не догма, всё течёт, всё развивается.

Конкретно в PHP, популярностью пользуется книга Объекты, шаблоны и методики программирования.

Полиморфизм в паттернах или Паттерн создания Паттернов

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

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

Антипаттерны

Раз есть паттерны, значит существуют и антипаттерны, это типовые ошибки, которые совершают программисты. Многие из них имеют вполне конкретные, часто шуточные, названия: "паблик морозов" или "божественный объект". Самое удивительное, что подходы считавшиеся раньше паттернами, иногда перетекают в раздел антипаттернов. Самый яркий пример это паттерн "Одиночка (Singleton)" – объект, который может существовать только в единственном экземпляре. Как показала жизнь, это плохо почти всегда. Кроме того, код с синглтонами крайне сложно тестировать.

Обучение паттернам

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

Попробуем разобраться. Как показывает практика, про паттерны все говорят, но мало кто действительно прочитал и понял их и может разумно применять. Причин этому несколько. Во-первых, крайне сложно осознать паттерн, не столкнувшись с реальной проблемой, которую он решает. Во-вторых, настоящее понимание паттернов завязано на те вещи, которые мы разбирали на протяжении всей профессии: именование (оно чертовски важно), менеджмент состояния, побочные эффекты, абстракции, расширяемость, полиморфизм подтипов. Без понимания этих вещей, попытка использовать паттерны почти наверняка превратится в культ карго. Причём из всего списка выше, паттерны, по эффекту оказываемому на код, находятся на последнем месте.

Важно понимать, что паттерны это не причина, а следствие. Остерегайтесь мышления в стиле "вот есть паттерн, как его натянуть на ситуацию". Сначала нужно понять ситуацию, а потом возникнет паттерн. И совершенно нормально, что первые годы разработки (а у кого-то и больше), задачи будут решаться так как получается. Обучение происходит через ошибки и неправильные решения, этого не надо бояться и избегать. Главное это последовательное улучшение, а здесь помогут книги и наставники (на работе или в сети). О том как лучше читать книги, в том числе по паттернам, мы писали в статье.