MVC – проблема или решение?
Репозитории, адаптеры, MVC, MVP и вся их родня, DRY, SOLID, RTFM... Любой разработчик (особенно имеющий дело с PHP и вебом) встречает эти заумные слова и аббревиатуры на каждом шагу. И... Знаете что? Мне это надоело. Хватит меня строить, дайте лучше полюбоваться на котиков.
Программы нужны, чтобы решать проблемы
Мы не просто так пишем свой код. Святой дух не снисходит на нас с небес и не изливается в наши файлы. Мы читаем техническое задание, разбиваем большую проблему на меньшие составляющие, и решаем эти маленькие проблемы одну за другой.
Каждая строчка кода решает одну конкретную проблему, будь это спасение мира, публикация фоточек няшных котиков или адаптация вёрстки к IE8. Если этот код решает проблему, не ломайте его!
Решение маленьких проблем становится частью чего-то большего. Чаще всего это большее со временем становится архитектурным «чёрным ящиком», который соответствует толстому тому спецификаций.
Но решает ли этот чёрный ящик проблему? И если да, то насколько это решение оптимально? И поймёт ли другой разработчик (или даже я спустя пару месяцев), что означает написанный мной код?
Один размер подходит всем
На сегодняшний день практически все разработчики вынуждены сопоставлять свои решения с моделью MVC. Те, кто имел неосторожность пренебречь MVC, категорически осуждаются коллегами. Но ни судьи, ни осуждённые не задаются вопросом: «Почему?».
Так почему же MVC – лучшая методология программирования? Обычно на это отвечают, что MVC:
- упрощает код;
- позволяет повторно использовать код;
- придаёт приложениям гибкость в применении;
- отвязывает разные функциональные части приложения друг от друга, позволяя развивать их по отдельности.
Звучит круто, но:
- правда ли это?
- значит ли это, что другие шаблоны по сравнению с MVC недостойны внимания?
В обоих случаях мы вынуждены ответить «Нет».
MVC не решает проблему сложности кода. Проблемы повторного использования и гибкости – тоже. И уж конечно, MVC не гарантирует разделение кода на независимые части.
Только квалификация разработчика способствует претворению всех этих пунктов в жизнь. Это мы – программисты, дизайнеры, администраторы – создаём быстрые, гибкие и универсальные приложения. Мы делали волшебные вещи задолго до того, как методология MVC стала звездой, и продолжим их делать и без неё.
Не стоит забывать, что MVC – это только шаблон решения, а не решение. И таких шаблонов – множество. «Адаптер», «фабрика», «одиночка», «обозреватель»...
Шаблоны должны помогать нам
Правда состоит в том, что шаблоны могут помочь нам писать простой, гибкий, и, главное, полезный код. Шаблоны программирования – это выработанная лучшими программистами за многие годы практика решения часто встречающихся проблем. И применимость каждой практики зависит от того, какая именно проблема вам попалась.
Нет лучших или худших шаблонов. Чтобы плыть по реке, вам отлично подойдёт лодка. Но на асфальтовой дороге это транспортное средство покажет себя не лучшим образом.
Шаблоны помогают нам компенсировать слабые стороны наших приёмов, языков и сред разработки. Например, «Фабрика» избавляет нас от рутинных ошибок в ситуации, когда необходимо создавать множество похожих друг на друга объектов.
«Модуль» помогает написать модульную систему на языке, который сам по себе имеет слабую или вообще никакую поддержку модульности (как, например, JavaScript).
«Наблюдатель» превосходен в обработке сообщений. MVC отделяет друг от друга процедуры хранения данных, их обработки и представления пользователю.
Но из всех шаблонов MVC используется намного чаще, чем нужно, и вот почему.
Однажды кто-то решил, что MVC подходит для всего, что написано на PHP и отображается в браузере. Отсюда пошли правила: модель (M) представляет строку в реляционной СУБД, контроллер (C) должен быть самым тонким слоем, а вид (V) должен быть написан на языке, который шаблонизатор превратит в PHP.
Но со временем накапливались противоречия. Например, кто-то догадался, что тонкий контроллер – не всегда хорошо. И создал новое правило: «Толстый контроллер – тонкая модель».
Дальше – больше. Неправильно применяемая модель MVC со временем дала рождение HMVC, MVA, MVP, MVVM, PAC...
MVC – это очередной «одиночка»
К сожалению, MVC – не единственный шаблон, которым массово злоупотребляют. Как однажды заметил Кейт Кейси: «Мы все периодически ищем что-то, что выглядело бы как глобальная переменная и вело себя, как глобальная переменная, но не являлось бы глобальной переменной».
И тут шаблон «Одиночка» ворвался в наш код. Внезапно использование global $var стало дурным тоном, и мы поспешно заменили эту дрянь на что-то вроде Global::getInstance()->var, считая при этом, что применяем ООП.
Шаблоны – это круто, разработчики – отстой!
Не поймите меня превратно. Методологии программирования – это круто. Они созданы для того, чтобы их использовали. Так используйте их осмысленно! Используйте их комплексно! Нет ничего хуже, чем разработчик, по-обезьяньи копирующий чей-то опыт в неподходящей для этого ситуации.
Умоляю вас: перестаньте насиловать по кругу одни и те же шаблоны!
Не изобретайте велосипед. Вы не первый пытаетесь создать модуль на JavaScript, вы не первый придумали систему передачи сообщений. Множество более опытных и талантливых людей уже побывали здесь до вас.
Не можете отделить запросы от PHP-кода? Пишете SELECT * FROM прямо в страницах? MVC наверняка поможет вам. Хотя, возможно, что для вашего приложения лучше подойдёт многоуровневая (Multitier) архитектура.
Не знаете, как организовать отложенную загрузку параметров? Вам поможет «одиночка» (Singleton).
Запутались в сотне похожих классов? Прекратите копипастить! Шаблон «Фабрика» (Factory) решит вашу проблему.
Размышляете о том, как проще организовать обмен данными между двумя сервисами? Используйте «Адаптеры» (Adapters).
Заключение
В зависимости от ситуации и стоящих перед вами задач, различные шаблоны программирования помогут вам написать простой, безопасный и стабильно работающий код.
Но будьте осторожны в применении шаблонов! Если вы обнаружили себя пишущим одностраничное приложение по правилам MVC – лучше закройте редактор, остыньте и начните заново.
И да пребудут с вами шаблоны!