Репозитории, Адаптеры, MVC со всеми его кузенами, SOLID, RTFM … Как разработчик (PHP), эти слова выкидывают вас из любого уголка сети. И я ненавижу это, с меня хватит. Перестань говорить мне, что делать, и покажи мне этих котят.
Программное обеспечение решает проблемы
Мы не просто пишем программное обеспечение. Код не падает с неба в наши файлы. Мы анализируем требования, разбиваем их на небольшие проблемы, которые знаем, как их решить, а затем решаем эти небольшие проблемы. Каждая строка кода, которую вы пишете, написали и будете писать, решает определенную проблему. Будь то, чтобы спасти мир, показать котят на экране или сделать так, чтобы они хорошо выглядели в IE8. Это там по причине, не трогай это!
Проблемы разрешимы, и решения этих проблем становятся частью чего-то большего. Черный ящик, который удовлетворяет всем начальным требованиям. Но как мы решаем эти проблемы? Является ли мое решение лучшим решением? Понимают ли другие разработчики (или я через 2 месяца), что я здесь сделал?
Одно решение подходит всем
При решении проблемы с веб-приложением мы вынуждены использовать MVC. Сообщество разработчиков часто осуждает тех, кто им не пользуется, но редко позволяет тем, кого они осуждают, спросить, почему.
Так почему же MVC лучший? Обычно бездумные причины:
- Уменьшенная сложность кода
- Повторное использование кода
- Повышенная гибкость
- Разъединенный код
Круто, звучит красиво, но …
- Это правда?
- У всех других моделей нет этих классных вещей?
Ответ — нет.
MVC не решает проблему сложности кода . Это также не решает проблему повторного использования кода или отсутствия гибкости . И это не гарантирует развязки кода .
Разработчики гарантируют снижение сложности кода. Это мы, программисты, программисты, разработчики и художники, пишем гибкий, разделенный и многократно используемый код. Нам нужен MVC столько, сколько нам нужен jQuery для document.getElementById (). Мы создавали отличное программное обеспечение еще до того, как кто-то слышал о MVC, и мы продолжим создавать отличные программы без MVC.
Не забывайте, что MVC — это шаблон, а не решение. Это соответствует всем остальным. Адаптеры, фабрики, синглтоны, модули, переводчики, наблюдатели …
Шаблоны не решают проблемы, они помогают нам
Шаблоны помогают нам писать гибкий, несвязный и простой в использовании код. Шаблон — это лучшая практика, которую разработчик может использовать для решения проблем. Эти передовые методы варьируются в зависимости от типа проблемы, которую вы решаете, топ-5 не существует . Лодка может быть действительно хороша при пересечении воды, но она не может вспахать поле.
Каждый шаблон имеет свои сильные и слабые стороны и предназначен для решения определенной ситуации. Например, шаблон Factory очень хорош в создании объектов. Шаблон Module помогает нам писать программные модули на языке, который не поддерживает (или только частично) модули (например, JavaScript). Сила паттерна Observer заключается в обработке событий, а MVC помогает нам отделить макет, манипулирование данными и контроллеры.
Но MVC сильно злоупотребляют, и вот почему:
Где-то в будущем кто-то решил, что это лучший подход ко всему, что написано на PHP и доступно через браузер. Затем пришло правило, что Модель должна иметь отношение 1: 1 к строке в базе данных, Контроллеры должны быть тонкими, а представления должны быть написаны на языке шаблонов, который компилируется в PHP.
Затем кто-то заметил, что «тонкий контроллер» не всегда лучший подход. Таким образом, они создали правило жирного контроллера, тонкой модели.
Несколько итераций спустя, мы сделали плохой MVC, чтобы родить HMVC, MVA, MVP, MVVM, PAC…
MVC — это новый синглтон (или IE8)
К сожалению, MVC — не единственная модель злоупотребления. Как приятно отмечает Кит :
Нам нужно что-то похожее на глобальное и действующее как глобальное, но на самом деле не глобальное.
Внезапно шаблон Singleton обнаружился повсюду в нашем коде. Вы можете написать дрянной код, чтобы люди не жаловались на использование global $var Вместо этого мы использовали шаблон Singleton Global::getInstance()->var
Шаблоны крутые, разработчики нет
Не поймите меня неправильно, шаблоны должны быть использованы. Но используйте их с умом. Используйте их вместе. Нет ничего хуже, чем разработчик, использующий неправильный шаблон по неправильной причине с неправильными намерениями.
Поэтому, пожалуйста, я вас умоляю. Не злоупотребляйте шаблонами.
Не изобретай велосипед. Вы не первый разработчик, пытающийся создавать модули на JavaScript, и не первый, кто разрабатывает программное обеспечение для обработки событий. Многие умные, более обученные специалисты сделали то же самое перед вами.
Не можете отделить MySQL от PHP? Вы пишете SELECT * FROM MVC, вероятно, поможет вам, или, может быть, вам лучше подойдет многоуровневая архитектура.
Возникли проблемы с отложенной загрузкой / чтением данных конфигурации? Синглтон может помочь здесь.
Является ли создание объекта определенного класса болью в заднице? Заводская модель действительно может помочь вам остаться СУХИМ.
Возникли проблемы с получением двух услуг для общения друг с другом? Адаптеры могут помочь.
Вывод
В зависимости от ситуации и рассматриваемой проблемы различные шаблоны могут помочь вам написать надежный, безопасный и понятный код. Просто будьте осторожны при их использовании — если вы поймаете себя на использовании шаблона MVC для 1-пейджера, ctrl+adel
Пусть шаблоны будут с вами!