Возможно ли добавить метод в класс с помощью php?

Question

[Misha7]

Возможно ли добавить метод в класс с помощью php скрипта без костылей. Например пользователю необходимо добавить функционал в cms. Он загружает скрипт, скрипт автоматически добавляется в качестве метода контроллера. Или более грамотно загружать сам контроллер?

Answer 1

[Сергей Протько]

Давайте определимся с тем что есть контроллер. Контроллер это какой-то компонент который управляет пользовательским вводом/выводом и на основе оного решает что делать собственно. В контексте WEB это некая штука, которая на вход принимает запрос а на выход должна вернуть ответ.

Если говорить в контексте ООП - у вас может быть один класс контроллер на запрос/страницу. И таких классов может быть бесчисленное множество. У вас может быть иерархия контроллеров. Да что угодно может быть.

Если вы хотите сделать расширяемую и главное удобно расширяемую логику - посмотрите в сторону dependency injection и аннотаций. Правда учитывая специфику запроса о чем-то хорошем наверное стоит просто забыть. Если хотите написать еще одну CMS - могу дать пару забавных идей. Так хоть CMS будет отличаться от миллионов существующих.

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

Comments

[Александр Маджугин]

Мне кажется именно то, что хочет реализовать ТС должно решаться с помощью ивентов. Вообще это очень хорошо если каждый значимый метод контроллера будет генерировать ивент. Более того - лучше пусть их будет два BeforeИмяМетода(аругментыМетода) и AfterИмяМетода(returnМетода).
Хотя и тут есть минусы.

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

[Сергей Протько]

Suntechnic: я не считаю что ивент на каждый чих это так уж хорошо. Можно обойтись намного более предсказуемыми штуками. Воутеры, декораторы и т.д. По поводу beforeMethod/afterMethod - попахивает хуками вордпрессов и друпалов. Только декораторы/композиция. Только хардкор. Никаких хуков. Нужно подменить реализацию - создаем декоратор. если хотим - обращаемся к оригинальной функциональности. Нет - оверрайдим ее как хотим. И да, это все можно компилить и кешировать.

У меня в голове пока вертелось две безумные идеи. Для начала хочу отметить что я не хотел бы видеть очередную универсальную CMS которая стремится за счет расширений решить проблемы всех и каждого. В поисках простенькой CMS для маркетологов, что бы те могли ваять себе странички и лэндинги с A/B тестированием более мение вменяемые варианты либо были ужасны внутри либо медленны (приходится прикручивать варниши всякие на продакшен что не каждый себе позволить может да и на стэйджинге и в админке всеравно все не сильно быстро). Не хватало чего-то такого же милого как piecrust/scuplin и т.д. но дружелюбного для маркетологов.

Первая идея довольно банальна. sir-trevor (или все больше скланяюсь к написанию своего редактора взяв за основу например makona-editor который по своей философии самое оно но безможно глючит и не поддерживается) и конструктор страничек. Только маркдаун, файлики и т.д. Разработчик жестко ограничивает контент менеджера определенным набором блоков. Никаких колонк и лэйаутов - если есть специфичные элементы такие - луше сделать блок конфигурабельный (картинка + текст с боку например) чем давать власть народу.

Вторая идея - генерация CMS на основе шаблонов. То есть вывернуть процесс разработки сайтиков наизнанку. Пишем шаблон страницы, какие-то мета-данные или конфигурацию (на базе twig-а делается очень легко) и генерируем структуру данных под эти шаблоны, контроллеры и прочее. Все генерируется. Все оптимизированно под текущее представление. Возможность генерировать миграции (diff) и.д. Никакиз 100500 запросов в базу для статической страницы (привет вордпресс). Но у меня правда нет таких задач потому решил не тратить время на вылизывание концепции. У нее есть свои проблемы кроме того что это банально сложно. Хотя может и не сильно сложно...

[Александр Маджугин]

Первое я пытался запилить. Там правда было + еще несколько "простых" идей, отправки страниц до завершения генерирования частями, для чего использовался сервер gatling и т.п. подобных выкрутасов. Но чтобы совсем хардкорно я делал на Tcl+Redis. Но забросил так как по сути для работы оно мне не надо, а для just for fun стало жрать много сил и времени. Да и гатлинг умер. Забил короче.
А вот как реализовывать второе я даже не могу представить пока. Надо подумать...

[Сергей Протько]

Suntechnic: разве гатлинг не для нагрузочных тестов?

[Александр Маджугин]

Сергей Протько: он подавал надежды и как рабочий сервер тогда.

Answer 2

[# a r t u r #]

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

Answer 3

[EgorVorozhtsov]

идея не очень хорошая) но как еще один вариант - использовать трейты

Answer 4

[Misha7]

Всем спасибо за внимание к вопросу! Нашел статью на хабре habrahabr.ru/post/57024.

Comments

[Сергей Протько]

Внимательно смотрите на количество минусов и комментарии. Если решитесь опубликовать CMS построенную на основе этого говнокода на хабре - будет так же.

[Misha7]

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

Появляются такие мысли: сделать класс работы с плагинами,
он подключает плагины из папки plugins, и создает их объекты, а класс user или администратор наследуют его. Но чем больше начинаю разбираться со всей системой плагинов и хуков, начинает казаться , что модель в mvc только усложняет весь процесс работы системы.

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

[Сергей Протько]

Misha7: я уже вам отвечал. Все о чем вы ведете речь уже изобретено - Dependency Injection. Но это потребует качественно другого подхода к проектированию CMS.

Ну и да... вы никогда не задумывались почему без кастылей никак? Потому что все кейсы предусмотреть невозможно. Кто-нибудь все-равно останется недоволен. Потому я считаю универсальные CMS пустой тратой времени.