Создание объектов с большим количеством полей

Yoskaldyr

"Спамер"
Партнер клуба
А и еще знает кто-то что-то подобное для js (в смысле aop)? Может есть какие форумы где нормальные js программисты сидят? А то что-то гуглю - везде вопросы типа о jquery и подобном :(
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Вообще как еще можно расширить какой-либо готовый продукт без AOP? Даже если там есть события, то в их всегда не хватает если надо расширять какую-то часть, где их нет.
Композиция, Адаптер, Бридж - куча паттернов (из энтерпрайзной жавы как раз) про то, как расширять без наследования.
Если оно хорошо выделяется в микросервис - ну, контейнеризируй, ходи снаружи в него по апи.

В JS же не классовый ооп, ты всегда можешь приклеивать методы и свойства на живой объект, там никаких сложных штук не надо.
 

Yoskaldyr

"Спамер"
Партнер клуба
Композиция, Адаптер, Бридж - куча паттернов (из энтерпрайзной жавы как раз) про то, как расширять без наследования.
Если оно хорошо выделяется в микросервис - ну, контейнеризируй, ходи снаружи в него по апи.
Повторюсь - речь идет о расширении практически любой части готового продукта без возможности изменения его исходников, речь не идет о написании своего продукта с возможностью простой правки его исходников и простой поддержкой.
И речь не идет о единичном расширении одного функционала, тут в большинстве случаев DI хватает (если он есть в продукте), а речь о нескольких расширениях (цепочка вызовов) одного и того же функционала.

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

В JS же не классовый ооп, ты всегда можешь приклеивать методы и свойства на живой объект, там никаких сложных штук не надо.
это если объект в глобальной видимости, но в последнее время в 90% случаев это не так.
Когда все закрытом локальном скоупе и исходный js-файл нельзя трогать, то все очень печально.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Если целью исходного пользователя была инкапсуляция поведения или данных, паттерны изменения поведения работают плохо, это логично )
Да, продукт написанный без цели расширения тяжело расширять. Никакой магии нет, которая может помочь в такой ситуации.
 

Yoskaldyr

"Спамер"
Партнер клуба
@флоппик Ок, предложи структуру продукта без AOP который можно расширить в любой точке? ну или в 90% случаев. И расширения могут быть полностью независимые и расширять одно и то же.

Может есть что-то готовое и рабочее?

P.S. Просто я не видел ни одной большой системы на PHP не на AOP, которую можно было бы расширять модулями (ивентов/хуков всегда не хватает)
 

fixxxer

К.О.
Партнер клуба
Движок этого форума архитектурно вещь очень сомнительная. :)

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

Yoskaldyr

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

треш типа опенкарта использует патчи исходного кода (поиск замена в исходниках с генерацией кеша результата), и это еще хуже aop и хуков.

из использующих aop знаю только magento и xenforo. и только их можно сильно модифицировать без изменения оригинала.

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

Yoskaldyr

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

Yoskaldyr

"Спамер"
Партнер клуба
постараюсь еще уточнить.

Т.е. как можно организовать конечный продукт типа (cms, форум, вики и т.д.), чтобы пользователи могли устанавливать дополнения для него, просто из магазина дополнений? И без aop (с aop и так понятно)

P.S. Я тоже знаю Композиция, Адаптер, Бридж и много других умных слов
 

fixxxer

К.О.
Партнер клуба
Спроектировать API для дополнений и реализовать его. :)

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

Вон посмотри на nginx, написан вообще на C (какие там, блин, АОП?), а все вполне себе расширяемо.
 

Yoskaldyr

"Спамер"
Партнер клуба
Дополнение это что-то меняющее оригинальный функционал, без изменения оригинального кода. Как оно реализовано не важно.

Да легко добавить включения мидлварей/триггер событий в переходах между слоями приложения (например для простого случая роутер-контроллер-вью, мидлвари между роутер-контроллер и контроллер-вью, но вариантов может быть куча в зависимости от того как реализована базовая архитектура). При таком подходе основная проблема, что обычно это покрывает только 70% возможных модификаций. Можно конечно сделать для 100% случаев, но это будет копипаст оригинальных методов базового приложения и это полностью неподдерживаемый код (да такое и в aop можно сделать, но обычно это редко применяется). Мидлвари на стыке слоев конечно лучше событий. И да этот подход с мидлварями уже практически aop - вызов до, после или вместо.

Также очень часто нужна модификация модификации. Например если брать тот же форум, то обычная практика, что нужна какая-то хитрая модификация галереи или другого популярного дополнения.

А nginx это вообще не в тему, там вообще все просто реквест, респонс и конфиг. Если брать пхп то очень близко это PSR7 и все что с ним связано.

P.S. Вообще кто-то больше пары раз писал расширения для какого либо продукта?
 

Yoskaldyr

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

fixxxer

К.О.
Партнер клуба
Если ты даже не можешь определиться с "кирпичиками", из которых все будет построено - то, конечно, никак.
Выложи исходники на гитхаб и пусть себе меняют что хотят. :)
 

Adelf

Administrator
Команда форума
Для меня пример самой крутой расширябельности - это IDEA. Шторм - это же просто плагин к ней :) И там внутри... куча точек расширения(просто интерфейс, который можно реализовать). Ты ее реализуешь... и среда спроектирована так, что к любой точке расширения могут быть прицеплены куча реализаторов.
Например, $test->test() - пользователь хочет переместиться к декларации метода test() и по большому счету куча плагинов могут предложить свои варианты куда этого юзера переместить. Если в итоге этот вариант только один - то среда просто идет туда. А если много - то предлагает юзеру выбор. И так везде.

Но это изначально система была спроектирована так. Нерасширябельный монолит ты ничем не разобьешь.
 

fixxxer

К.О.
Партнер клуба
Вот, кстати, да, идеальный пример. И никаких АОП :)
Немного напрягает отсутствие инверсии зависимостей там где явно напрашивается, но тут еще вопрос производительности ведь.
 

Yoskaldyr

"Спамер"
Партнер клуба
Всетаки idea немного не тот пример. IDE значительно более блочный продукт и размер этих логических блоков кода небольшой. Поэтому с точки с точки зрения добавления бизнес логики, редко приходится менять что внутри этих блоков. Плюс это разные языки программирования, можно сделать долгий старт, можно добавить хуки/точки инжекта куда угодно и это практически не будет влиять на производительность. А если и надо заменять, то используют копипаст этого блока, и это не является проблемой. Т.к. для такого большого продукта как IDEA эти небольшие блоки меняются очень редко. Это десктоп приложение, и там приемлемы совсем другие компромиссы.

То же самое нельзя сделать с пхп. В результате будет минимум 2 из 3: тормоз, куча магии или нечитабельный код (и это даже в сравнении с aop).
По идее все можно решить добавить точки инжекта во все более менее критические точки приложения. Но тогда этих точек будут тысячи. И это будет сказываться на читаемости такого кода.

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

Это просто статистика, т.к. постоянно есть спрос на модификации готовых решений.

Я знаю что мало программистов напрямую общаются с заказчиками, и что здесь на форуме практически нет программистов связанных с модификацией/интеграцией готовых решений. Потому вопросы не совсем ложатся на стандартные практики. Когда пишется свое приложение для него тупо писать расширение, если можно (а вообще и нужно) просто исправить основной код. Я полностью поддерживаю что для разработки обычных приложений aop нафиг не сдалось (учитывая сложность тестирования и сложность поддержки).

Но речь идет о модульной и полностью расширяемой системе, где не хотелось бы писать точки инжекта мидлварей в любых более менее значимых местах (просто их будет слишком уж много). В том же ксенфоро и мадженто aop используется именно для композиции (хотя и реализовано это все через наследование), а не для aop как такового. И в них все так же есть и обычные события/хуки в тех местах где aop излишне.

p.s. когда говорю об aop я не имею ввиду именно реализацию go-aop, а имею ввиду сам принцип.
 
Последнее редактирование:

Adelf

Administrator
Команда форума
Это называется кастомизациями под отдельного заказчика. И это всегда сложно :) Ну и да.. специфика php в итоге сказывается на производительности. Я такую систему видел вживую и немного работал.. но она была на C#. Там все легко конфигурится и работает без тормозов.
 

Yoskaldyr

"Спамер"
Партнер клуба
Я такую систему видел вживую и немного работал.
И как там было реализовано? Хуки на каждый чих?
Просто из того что я видел на пхп расширяемость в ксенфоро и мадженте самая адекватная, но и там и там основана на принципах aop, хотя конечно нигде в доках так не называется (типа просто отнаследуем виртуальный класс). Все остальное что видел это хуки/события и полный хардкор типа патчей на исходный код.
 
Последнее редактирование:

fixxxer

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

Интеграция обычно со сторонними сервисами через всякие API. Так, чтобы коробочные продукты... я такого лет 15 не видел (вордпрессы не считаются).
 

AmdY

Пью пиво
Команда форума
Я уже плохо помню, но мы вроде вообще без хуков и явного аоп обходились. Были объекты в стиле javabeans, которые конфигурировались через конфиги и передовались через цепочки, которые опять же конфигурировались через конфиги. Из-за всякой кривизны и непродуманности активно использовали паттерн декоратор, в который заворачивали эти объекты, когда надо было перееопределить что-то неконфигуриромое и хак с наследованием для доступа к протектит методам.
Я продвигал идею АОП, но не удалось убедить команду даже для кастомной реализации. Но тогда не было go-aop и речь шла о pecl расширении.
В любом случае, надо много шишек набить, чтобы сделать кучу точек входа и изменений, какой бы ты подход не юзал, всегда найдётся хотелка. У меня до сих пор глаз дёргается когда вижу в коде private, final, static

А по поводу AOP лучше дёрнуть самого Лисаченко, он кажись его в боевых проектах использует и не для cms-cmf со стабильным ядром.
 
Сверху