Блог


Шаблоны проектирования. Помощники или стереотипы?

Те программисты, кто умудрился продвинуться чуть дальше Hello World, рано или поздно сталкиваются с такими понятиями, как GRASP, GoF, SOLID и другими рекомендациями. Это хорошо, но плохо то, что эти практики, с подачи не совсем опытных адептов ООП воспринимаются, как правила. А это не так. Между правилами и рекомендациями довольно серьёзные различия.

Правило - штука, обязательная к исполнению. Это требование. Если сделать что-то не по правилам, то либо результат будет не тем, что ожидается, либо будут неприятности.


Рекомендация, это совет. Штука не обязательная к выполнению. Это накопленный и обобщенный опыт, передаваемый малоопытным субъектам.

Для примера - синтаксис языка программирования, это правило. Если использовать другой синтаксис, то либо будет ошибка, либо программа не запустится в выбранной среде. Вполне корректную программу на JS невозможно запустить в PHP, так как нарушено правило интерпретации.

Применение схемы MVC для веб-приложений, это рекомендация. Конечно это хорошая схема, однако совершенно не обязательная. Во-первых нет смысла городить этот огород, если делается пару-страничный лендинг. Во-вторых, есть альтернативные схемы: HMVC, MVP, MVVM, MOVE и так далее. И совсем не факт, что построенное по любой из этих схем приложение, будет работать хуже, чем на MVC.
Просто это фундаментальный и самый популярный паттерн, потому то его советуют гораздо чаще, чем остальные.

Однако сказать, что если приложение не использует MVC, то это плохое приложение - это, мягко скажем, не совсем профессионально. 

Это же касается и SOLID и GRASP и других, знаменитых принципов программирования. Это хорошие, добротные, проверенные тысячами программистов, шаблоны. Но они все носят рекомендательный характер. И совершенно не обязательны к исполнению. Иногда сознательное отступление от них вовсе не являются bad-practices. 

Не торопитесь обвинять меня в вероотступничестве и ереси. Я сейчас обосную.

Сначала небольшое отступление. Есть такое понятие - "стереотип". Или "шаблонное мышление". В сети полно информации на эту тему, вот допустим лаконичная и поучительная статья. Кому лень читать, лейбмотив:

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


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

В высказываниях практически каждого авторитетного программиста, который своим творчеством внес вклад в развитие информатики,  можно встретить что то подобное, что сказал Фаулер: 

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


Дело не в том, что паттерны опасны или вредны. Дело в том, что велика вероятность применить их неверно. Кроме того, существуют различные мнения и даже прямопротивоположные принципы построения архитектур. Яркий пример - подход MIT против worse is better


Есть две главные ошибки использования паттернов.
1. Чрезмерное ими увлечение
2. Принятие паттернов, как безапелляционные законы.

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

Допустим первый принцип SOLIDПринцип единственной обязанности  
На каждый класс должна быть возложена одна-единственная обязанность.

Это понятно и разумно. Если в один класс собрать и роутинг, и работу с СУБД, и рендеринг, и хор Турецкого, и сборную по футболу, то получится нарушение принципа, и в лучшем случае GOD-объект, а в худшем - спагетти-код. Но эта рекомендация имеет и обратные пределы. Если увлечься этим принципом, то получится другая крайность, антипод спагетти-коду: френкен-код. То есть монстр, сшитый из маленьких кусочков. И то, и другое - антипаттерны.

С другой стороны, если принять этот принцип за закон, то допустим будет сложно сделать портабл версию приложения. То есть не всегда его применение разумно.

Или мой любимый пример. Последний пункт из SOLID: Принцип инверсии зависимостей
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. 

В переводе на мирской язык - душа не должна зависеть от тела. Тело должно зависеть от души.

Здесь немного подробнее, за одно расскажу про еще один интересный момент. Дело в том, что почему то априори рассово-верным считается дизайн фреймворка. Но на самом деле есть вполне равноправная схема "сборка библиотек". Многие считают, что это одно и то же. На самом деле это не так. И принципиальное различие между ними, это как раз соблюдение DIP (Dependency Inversion Principle). Принципа инверсии зависимостей.

В схеме фреймворка он крайне желателен. А в схеме сборки - наоборт, от него только вред. Все дело в приоритетах и способе взаимодействия пользовательских скриптов и библиотек.

Вот тут я подробно это описал.

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

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

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

Ну а если вы, достигли определенного уровня, познав дзен паттернов, и начинаете убеждать других, что это законы, а не рекомендации, то уподобляетесь невежественным адептам секты каких-нибудь "свидетелей Иеговы". Не видя ничего за пределами придуманного для вас мирка, и пытаясь затянуть в него неокрепшие умы всеми правдами и неправдами. Что не делает чести, и никак не свидетельствует о профессионализме.

Подведу итог словами того же Фаулера.

Паттерны необходимо изучать. Для того, чтобы знать, где их применять не нужно.

И еще. Программисты, по складу менталитета, делятся на две категории. Одни гуманитарии, другие технари. Ну или творцы и ремесленники.

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

Гуманитариям присущ творческий подход. Они не боятся ошибок и пробуют новые, нестандарные решения. Их путь тернист, их обвиняют в bad-practices, они чаще ошибаются, но жизнь их не так скучна и однообразна. Они способны на яркие и революционные решения. И они в большинстве случаев являются двигателями прогресса.

Кто вы по этой градации - решать вам. Все зависит от поставленных в жизни целей, и от свойств характера. Главное быть в гармонии с самим собой.



Рекомендую ознакомиться:

1. Проектирования больше нет?
2. Немного про архитектуру
3. Шаблонное мышление
4. Костыльный программист


Теги: PHP | Флейм

Комментарии (0)


 
Наверх