Бинарный салют, друзья! На связи снова EngineerSpock.
Мы уже как-то раз вскользь касались темы паттернов проектирования и стоит ли их учить. То был разбор ролика Лёши Корепанова, где он рассуждал на эту тему и в целом приходил к выводу, что учить паттерны не обязательно. Посмотрите тот разбор по ссылке, весьма познавательно.
В этой статье я хочу несколько более подробно поговорить об этой теме, постараться всех успокоить и дать рекомендации по изучению паттернов.
GoF-паттерны и преимущества их применения
В первую очередь, в этой статье мы будем говорить о так называемых GoF-паттернах. Напомню супер-кратко, что GoF – расшифровывается как Gang of Four или банда четырёх, состоящая из 4-х авторов, первыми описавших и проведших категоризацию паттернов проектирования в классическом труде под названием «Паттерны объектно-ориентированного проектирования».
Паттерны проектирования – это, иначе говоря, программные шаблонные решения, призванные решать часто встречающиеся, похожие друг на друга задачи.
Если вкратце, то грамотно применяемые паттерны проектирования позволяют:
- создавать более гибкий и понятный код
Этот самый первый пункт ударит по больному месту тем, кто выступает против паттернов и мы разберём почему. Смысл моего утверждения в том, что паттерны, как правило имеют довольно сложные конструкции относительно альтернативных прямолинейных решений, однако, правильно приготовленные - они всё же более гибкие и понятные. - сокращать время разработки
Если задача была миллион раз решена до вас, то довольно мудрым решением будет воспользоваться накопленным опытом и просто использовать то, что работает и решает вашу проблему. - упрощать коммуникацию между разработчиками, используя общепринятые наименования паттернов. Т.е., когда программист Пупкин говорит программисту Губкину, что можно применить паттерн «Состояние», при условии, что оба знакомы с GoF-паттернами, оба сразу же понимают о чём они говорят.
Аргументы против шаблонов проектирования
Теперь давайте рассмотрим основные тейки, так или иначе направленные против паттернов
1. Некоторые разработчики считают, что изучение паттернов проектирования требует слишком много времени и усилий, особенно если они уже занимаются программированием и имеют определенный опыт. Они могут полагать, что лучше использовать свое время на изучение более конкретных и практических навыков, связанных с их проектами.
2. Некоторые разработчики считают, что паттерны проектирования слишком сложны и абстрактны для практического использования. Они могут считать, что это концептуальные модели, которые не всегда могут быть применены в реальной жизни, и что использование конкретных решений для конкретных задач является более эффективным.
3. Сторонники мнения, что паттерны проектирования учить не нужно, иногда указывают на большое количество различных паттернов, которые могут быть запутывающими для начинающих разработчиков. И скорее запутывают разработчиков, которые начинают их применять ни к селу, ни к городу.
4. Множество разработчиков могут считать, что использование паттернов проектирования часто приводит к излишней сложности кода, что приводит к трудностям при его поддержке и обновлении.
Разбор аргументов против применения шаблонов проектирования
Давайте разберём последовательно все эти основные тейки против изучения паттернов или шаблонов проектирования.
Первое. Изучение паттернов слишком трудозатратно, лучше заняться чем-то иным.
Ну, приоритет в изучении тех или иных тем, касающихся программирования каждый расставляет сам, исходя конкретно из личной ситуации. Означает ли это, что у большинства приоритет должен быть таким, что паттерны оттуда будут исключены совсем или стоять на самых последних местах? Отнюдь. Я как раз считаю, что большинству программистов, изучение паттернов необходимо, и пусть этот пункт может не стоять на первых местах, но и задвигать это в дальний ящик я бы не стал. Дело в том, что лишь небольшая доля программистов может либо совсем не думать о паттернах, либо думать о них мало. Что это за программисты? Это программисты, которые делают всё в одно лицо на постоянной основе, либо те, кто работает над небольшими проектами. В таких случаях значение применения паттернов не столь велико. Все условно классические программисты, занятые разработкой систем среднего и большого размеров к вышеуказанной категории никак, не относятся.
Второй пункт утверждает, что паттерны слишком абстракты и что необходимо применять конкретные решения для конкретных проблем.
В этом утверждении есть рациональное зерно. Однако, это неверно в целом. Да, действительно, есть ситуации, когда для решения конкретной проблемы требуется конкретный специфический подход. Однако, не все возникающие перед программистами задачи являются такими уж уникальными. Доказать это очень и очень просто. Если бы дело обстояло так как заявляется в этом пункте, то сами языки программирования не впитывали бы в себя как губки паттерны проектирования. Я говорю о том, что множество современных языков программирования имеют встроенные конструкции, которые являются реализацией тех или иных шаблонов проектирования. В C# мы имеем встроенный паттерн Observer в виде ивентов, а в Python имеем мощные декораторы, являющиеся реализацией шаблона «декоратор». Примеров масса, на самом деле. Это лишь парочка.
Третий пункт говорит о том, что паттернов слишком много, что они запутывают и в результате их применяют не там и не так.
Ну, что тут скажешь, это не проблема самих паттернов. Это проблема тех, кто их применяет и тех, кто создаёт панику вокруг необходимости срочно учить паттерны, желательно зубрить классические реализации, а если не умеешь, то никакой ты не программист. Вокруг темы паттернов в своё время действительно было очень много хайпа и как и в любой дискуссии всегда появляются различные фанатичные приверженцы тех или иных идей, в данном случае идеи о незыблемости классических реализаций, и о том, что паттерны надо применять, обязательно надо, надо очень надо. Надо может и надо, но создавать вокруг паттернов нездоровый ажиотаж не надо.
В результате этого хайпа, у многих появилось желание во что бы то ни стало разобраться и выучить все GoF-паттерны. Идея похвальная, но, в большинстве случаев, неадекватная. Далее разберём почему.
И последний пункт. Использование шаблонов проектирования часто приводит к излишней сложности кода.
Это опять же не проблема самих паттернов, а тех, кто их применяет. Если вы для реализации hello world заводите три фабрики, то у вас явные проблемы с пониманием паттернов. Причём, возможно даже, не GoF-паттернов, а метапринципов, которые главенствуют над всеми остальными паттернами.
О каких метапринципах идёт речь? В первую очередь о принципах KISS (Keep it Simple Stupid) и YAGNI (You Ain’t Gonna Need It). Когда этими принципами на проекте постоянно жертвуют в угоду наворачивания паттернов – проблемы неминуемы.
Советы по изучению паттернов проектирования
Надеюсь, я прояснил почему все контраргументы против изучения паттернов не особо состоятельны. Теперь несколько советов касательно того как изучать шаблоны проектирования:
- Изучайте паттерны по мере необходимости: начните с самых распространенных паттернов проектирования. Возможно, вы удивитесь, но далеко не все паттерны применяют с одинаковой частотой. Об это скажу далее.
- Практикуйтесь в написании кода с применением паттернов проектирования. Для этого ознакомьтесь со смыслом и примерной реализацией основных паттернов и при программировании держите в голове возможность их применения. Я бы посоветовал попрактиковаться на довольно сложном пет-проджекте. Например, попробуйте реализовать мани-трекер, там простора для грамотного применения шаблонов полно. Без практики прочувствовать паттерны невозможно.
- Изучайте open source-проекты. Кстати, возможно, стоит завести рубрику с разбором решений из open-source. Там вы найдёте полно грамотного применения паттернов.
- Изучайте паттерны проектирования в контексте принципов: в контексте метапринципов и принципов SOLID. Это поможет вам лучше понимать, как паттерны проектирования используются в больших приложениях.
Теперь пару слов о глупости идеи кинуться и начать учить все паттерны без разбора и в особенности учить конкретные реализации.
Все классические GoF-паттерны разбиты на три категории: порождающие, структурные и поведенческие. Пять штук порождающих, семь структурных и одиннадцать поведенческих.
Проблема в вышеозначенном подходе заключается в том, что не все паттерны одинаково полезны. Точнее, некоторые паттерны применяются очень редко. Например, мне кажется, я в жизни ни разу на практике не применил паттерн «Мост», в основном применяющийся при построении сложных объектных иерархий. Паттерн «посетитель» применяется в целом почаще, но не сказать, чтобы очень часто. В жизни я посетителя применил по пальцам можно пересчитать. И так далее.
Вот вам мой вполне себе субъективный набор паттернов, с которых вам стоит начать их изучение:
- Factory Method
- Singleton
- Builder
- Adapter
- Decorator
- Facade
- Proxy
- Command
- Iterator
- Mediator
- Observer
- State
- Strategy
- Template Method
Я их выставил без какого-либо приоритета, можете изучать их в рамках их категорий, можете в рандомном порядке. Главное, не надо вот этого помешательства: я упёрся в паттерн мост, не понимаю зачем оно надо, где применить, моя жизнь окончена, я плохой программист и так далее. Не надо вот этого всего и всё будет хорошо.
Не зацикливайтесь на конкретной реализации конкретного паттерна. Один и тот же паттерн как правило может быть реализован разными способами и на разных языках реализация может существенно отличаться. Поэтому надо понимать смысл, а не учить реализации на C/C++/C# или любом другом ЯП.
Итоги
В любом случае, важно понимать, что паттерны проектирования не являются универсальным решением для всех задач и проектов, и что их использование может быть не всегда уместным. Однако, для большинства проектов и задач использование паттернов проектирования может принести большую пользу, так как они позволяют создавать более гибкий, поддерживаемый и расширяемый код.
Изучение паттернов проектирования также может помочь разработчикам развивать свой профессиональный уровень и расширять свои знания в области программирования. Они могут помочь разработчикам лучше понимать принципы объектно-ориентированного программирования и архитектурных решений.
Таким образом, хотя есть некоторые контр-аргументы против изучения паттернов проектирования, большинство вменяемых разработчиков считают, что понимание и использование паттернов является важным навыком для успешной работы в области программирования и разработки программного обеспечения.
Ну, а я, как всегда, хочу напомнить, что, как истинный инфоцыган, абсолютно все статьи и ролики на ютуб-канале я пишу и снимаю для того, чтобы на вас заработать. Поэтому напоминаю, что у нас есть отличный курс по принципам SOLID и шаблонам проектирования на Python: https://stepik.org/a/103603/pay?promo=ada6bde20f3df5f3
