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

Все шаблоны я писал сам, но, естественно, ориентировался на существующий код и описания (почти всё с википедии и книг по Java). В основном, конечно это Java и C#, поскольку паттерны были придуманы для «больших» языков, а реализации в PHP лишь пытаются повторить их код. Это одна из проблем, поскольку PHP сам по себе уже имеет ряд готовых решений где использование шаблона просто не имеет смысла. Например шаблон Prototype (Прототип) реализуется через clone и ничего придумывать не нужно. Или шаблон Iterator (Итератор) по сути сводится к перебору массива, поскольку массив в PHP — универсальная структура и может содержать не только простые данные, вроде строк и чисел, но и сложные — объекты. Конечно, можно перевести код этих шаблонов с Java на PHP, но большого смысла это иметь не будет, разве что для теоретического изучения.

Шаблонов проектирования много и разобраться в них сходу не получится. Мои варианты шаблонов имеют пару особенностей. Первая — это реальный исполняемый код. То есть вы можете запустить на сервере index.php и получите результат в браузер. Сам шаблон и вся его работа размещена в одном файле для удобства (чтобы не прыгать по нескольким файлам).

Читать ➝

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

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

Есть даже такое выражение «Композиция лучше наследования», которое хорошо известно программистам Java или С++. Попробуем посмотреть на эти вопросы с точки зрения PHP.

Читать ➝

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

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

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

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

Читать ➝

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

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

Читать ➝

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

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

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

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

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

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