Следует учитывать, что в PHP несколько упрощенная реализация ООП (объектно-ориентированное программирование). Поэтому, когда речь идёт об ООП как абстрактной парадигме, то следует использовать какой-то более серьёзный язык, вроде Java, С++ или Object Pascal. Потому что на этих языкам можно посмотреть практическую реализацию принципов ООП. В PHP программисты пытаются подражать другим ЯП, что в итоге приводит к излишней сложности и путанице, поскольку язык сам по себе не позволяет сделать «как в теории».

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

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

Попробуем разобраться. Кратенько без «воды».

Читать дальше...

Шаблон MF продолжает развиваться. Еще несколько дней на тестирование и все клиенты получат обновление. Я добавил два новых компонента шапки. Первый — более простой блок меню, где только лого, само меню и соц.иконки, и второй — рекламный блок, где задаётся произвольный текст и картинка (рабочее демо).

Также сделал два новых блока и добавил праздничную скидку на покупку MF (об этом ниже).

Читать дальше...

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

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

От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.

Несколько лет назад я делал приватный проект, где было много математики и обработки данных. Поскольку хотелось сразу сделать правильно, то использовал ООП, классы, статические методы и ряд новых функций PHP 5.5. После того, как проект загрузили на «боевой» сервер, всё «разрушилось», поскольку там стояла PHP 5.2, которую (по каким-то особым причинам), нельзя было обновить. Код пришлось переписывать с учётом старой версии. Теперь, если сервер всё-таки обновят до PHP 7.x, код опять придётся переписывать, поскольку между версиями нет полной совместимости.

Не существует идеального и универсального решения для веб-проекта. Они все обязательно окажутся в тупике из-за изначально непродуманной архитектуры или объективных причин, вроде несовместимости между PHP-версиями. Даже если сделать как «по теории», в процессе развития проект окажется неспособным решить какие-то новые задачи, поскольку мы элементарно не можем предсказывать будущее. Единственным способом двигаться дальше будет только революционный подход, который подразумевает полную или частичную потерю совместимости со старым кодом.

Через это прошли все фреймворки, системы, библиотеки (любого ЯП) и т.п., которые продолжают развиваться. По мере роста, вначале идёт эволюционный подход, когда возможностей хватает, но потом резкий скачок к новой версии. Для того, чтобы упростить такие переходы, архитектура приложения должна изначально подразумевать такую «версионность».

При разработке php-проекта часто возникает потребность разделить его на небольшие части — модули. Слово «модули» довольно расплывчато и в разных случаях может трактоваться по своему, но в данном случае речь идёт только о том, что модуль — это некий код, который может представлять собой единую сущность.

Программно модуль может быть набором классов, функций и файлов. Он может содержать html-код, css-стили, js-скрипты, изображения и т.п. То есть не важно как в реальности реализован модуль, главное это то, что мы можем его воспринимать как единое целое.

Когда в проекте много php-классов, то возникает проблема подключения их файлов. Например есть классы Class1 и Class2. Для того, чтобы их использовать, вначале нужно подключить их php-файлы. Само по себе подключение — это обычные require или include, поэтому задача сводится к тому, чтобы указать правильный путь к php-файлу. По мере, того как классов становится всё больше, возникает серьезная проблема с подключением каждого файла класса. В идеале процесс подключения должен быть автоматизирован и в PHP для этого используется механизм автозагрузчика.

Автозагрузчик будет срабатывать каждый раз, когда в коде встретится неизвестный класс. Сам по себе автозагрузчик представляет собой обычную функцию, которая и выполняет подключение файла с помощью require. Функция автозагрузчика должна быть зарегистрирована через специальную функцию spl_autoload_register. При этом функций можно зарегистрировать несколько — PHP последовательно их выполнит пока не подключит файл с нужным классом.

Давайте рассмотрим несколько примеров, чтобы лучше понять как это всё работает (исходные файлы можно скачать в конце статьи).

Пока я не стал баловаться программированием на Javа, особо не задумывался над использованием MVC в PHP. Обычно действуешь по своему опыту или как это принято в php-фреймворке (или CMS, не важно). Тем более почти все фреймворки декларируют свою преданность концепции MVC: дескать вот у нас всё сделано правильно, по теории.

После Java, где объектное программирование возведено почти в абсолют, MVC в PHP выглядит уже достаточно «бледно», пытаясь хоть как-то соответствовать этой концепции. Интересно ещё и то, что php-разработчики Model-View-Controller видят по разному и не всегда верно.