-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Создание объектов с большим количеством полей
- Автор темы Yoskaldyr
- Дата начала
Композиция, Адаптер, Бридж - куча паттернов (из энтерпрайзной жавы как раз) про то, как расширять без наследования.
Если оно хорошо выделяется в микросервис - ну, контейнеризируй, ходи снаружи в него по апи.
В JS же не классовый ооп, ты всегда можешь приклеивать методы и свойства на живой объект, там никаких сложных штук не надо.
Повторюсь - речь идет о расширении практически любой части готового продукта без возможности изменения его исходников, речь не идет о написании своего продукта с возможностью простой правки его исходников и простой поддержкой.
И речь не идет о единичном расширении одного функционала, тут в большинстве случаев DI хватает (если он есть в продукте), а речь о нескольких расширениях (цепочка вызовов) одного и того же функционала.
типичный пример движок этого форума - несколько дополнений могут расширять одни и те же сущности (вот в нем как раз AOP и используется, через наследование, но это уже особенности реализации)
это если объект в глобальной видимости, но в последнее время в 90% случаев это не так.
Когда все закрытом локальном скоупе и исходный js-файл нельзя трогать, то все очень печально.
Если целью исходного пользователя была инкапсуляция поведения или данных, паттерны изменения поведения работают плохо, это логично )
Да, продукт написанный без цели расширения тяжело расширять. Никакой магии нет, которая может помочь в такой ситуации.
Да, продукт написанный без цели расширения тяжело расширять. Никакой магии нет, которая может помочь в такой ситуации.
@флоппик Ок, предложи структуру продукта без AOP который можно расширить в любой точке? ну или в 90% случаев. И расширения могут быть полностью независимые и расширять одно и то же.
Может есть что-то готовое и рабочее?
P.S. Просто я не видел ни одной большой системы на PHP не на AOP, которую можно было бы расширять модулями (ивентов/хуков всегда не хватает)
Может есть что-то готовое и рабочее?
P.S. Просто я не видел ни одной большой системы на PHP не на AOP, которую можно было бы расширять модулями (ивентов/хуков всегда не хватает)
так я насчет качества движка форума и не говорю. Я говорю о принципе расширения.
Для примера взять большинство популярных продуктов предствленных на рынке (медиавики, вордпресс, большинство движков форумов), почти все используют хуки/события, но при реальной разработке сторонней модификации, это всегда не хватает.
треш типа опенкарта использует патчи исходного кода (поиск замена в исходниках с генерацией кеша результата), и это еще хуже aop и хуков.
из использующих aop знаю только magento и xenforo. и только их можно сильно модифицировать без изменения оригинала.
я вот просто думаю какие могут быть альтернативы aop, хотя да aop сомнительная практика, особенно когда на аннотациях.
Для примера взять большинство популярных продуктов предствленных на рынке (медиавики, вордпресс, большинство движков форумов), почти все используют хуки/события, но при реальной разработке сторонней модификации, это всегда не хватает.
треш типа опенкарта использует патчи исходного кода (поиск замена в исходниках с генерацией кеша результата), и это еще хуже aop и хуков.
из использующих aop знаю только magento и xenforo. и только их можно сильно модифицировать без изменения оригинала.
я вот просто думаю какие могут быть альтернативы aop, хотя да aop сомнительная практика, особенно когда на аннотациях.
постараюсь еще уточнить.
Т.е. как можно организовать конечный продукт типа (cms, форум, вики и т.д.), чтобы пользователи могли устанавливать дополнения для него, просто из магазина дополнений? И без aop (с aop и так понятно)
P.S. Я тоже знаю Композиция, Адаптер, Бридж и много других умных слов
Т.е. как можно организовать конечный продукт типа (cms, форум, вики и т.д.), чтобы пользователи могли устанавливать дополнения для него, просто из магазина дополнений? И без aop (с aop и так понятно)
P.S. Я тоже знаю Композиция, Адаптер, Бридж и много других умных слов
Спроектировать API для дополнений и реализовать его. 
Дополнение - это модуль, реализующий определенные интерфейсы. Установил, зарегистрировался, а дальше типа как в миллдварях, вызываем всех по очереди (ну приоритеты еще могут быть, допустим).
Вон посмотри на nginx, написан вообще на C (какие там, блин, АОП?), а все вполне себе расширяемо.
Дополнение - это модуль, реализующий определенные интерфейсы. Установил, зарегистрировался, а дальше типа как в миллдварях, вызываем всех по очереди (ну приоритеты еще могут быть, допустим).
Вон посмотри на nginx, написан вообще на C (какие там, блин, АОП?), а все вполне себе расширяемо.
Дополнение это что-то меняющее оригинальный функционал, без изменения оригинального кода. Как оно реализовано не важно.
Да легко добавить включения мидлварей/триггер событий в переходах между слоями приложения (например для простого случая роутер-контроллер-вью, мидлвари между роутер-контроллер и контроллер-вью, но вариантов может быть куча в зависимости от того как реализована базовая архитектура). При таком подходе основная проблема, что обычно это покрывает только 70% возможных модификаций. Можно конечно сделать для 100% случаев, но это будет копипаст оригинальных методов базового приложения и это полностью неподдерживаемый код (да такое и в aop можно сделать, но обычно это редко применяется). Мидлвари на стыке слоев конечно лучше событий. И да этот подход с мидлварями уже практически aop - вызов до, после или вместо.
Также очень часто нужна модификация модификации. Например если брать тот же форум, то обычная практика, что нужна какая-то хитрая модификация галереи или другого популярного дополнения.
А nginx это вообще не в тему, там вообще все просто реквест, респонс и конфиг. Если брать пхп то очень близко это PSR7 и все что с ним связано.
P.S. Вообще кто-то больше пары раз писал расширения для какого либо продукта?
Да легко добавить включения мидлварей/триггер событий в переходах между слоями приложения (например для простого случая роутер-контроллер-вью, мидлвари между роутер-контроллер и контроллер-вью, но вариантов может быть куча в зависимости от того как реализована базовая архитектура). При таком подходе основная проблема, что обычно это покрывает только 70% возможных модификаций. Можно конечно сделать для 100% случаев, но это будет копипаст оригинальных методов базового приложения и это полностью неподдерживаемый код (да такое и в aop можно сделать, но обычно это редко применяется). Мидлвари на стыке слоев конечно лучше событий. И да этот подход с мидлварями уже практически aop - вызов до, после или вместо.
Также очень часто нужна модификация модификации. Например если брать тот же форум, то обычная практика, что нужна какая-то хитрая модификация галереи или другого популярного дополнения.
А nginx это вообще не в тему, там вообще все просто реквест, респонс и конфиг. Если брать пхп то очень близко это PSR7 и все что с ним связано.
P.S. Вообще кто-то больше пары раз писал расширения для какого либо продукта?
Для меня пример самой крутой расширябельности - это IDEA. Шторм - это же просто плагин к ней И там внутри... куча точек расширения(просто интерфейс, который можно реализовать). Ты ее реализуешь... и среда спроектирована так, что к любой точке расширения могут быть прицеплены куча реализаторов.
Например, $test->test() - пользователь хочет переместиться к декларации метода test() и по большому счету куча плагинов могут предложить свои варианты куда этого юзера переместить. Если в итоге этот вариант только один - то среда просто идет туда. А если много - то предлагает юзеру выбор. И так везде.
Но это изначально система была спроектирована так. Нерасширябельный монолит ты ничем не разобьешь.
И там внутри... куча точек расширения(просто интерфейс, который можно реализовать). Ты ее реализуешь... и среда спроектирована так, что к любой точке расширения могут быть прицеплены куча реализаторов.Например, $test->test() - пользователь хочет переместиться к декларации метода test() и по большому счету куча плагинов могут предложить свои варианты куда этого юзера переместить. Если в итоге этот вариант только один - то среда просто идет туда. А если много - то предлагает юзеру выбор. И так везде.
Но это изначально система была спроектирована так. Нерасширябельный монолит ты ничем не разобьешь.
Всетаки idea немного не тот пример. IDE значительно более блочный продукт и размер этих логических блоков кода небольшой. Поэтому с точки с точки зрения добавления бизнес логики, редко приходится менять что внутри этих блоков. Плюс это разные языки программирования, можно сделать долгий старт, можно добавить хуки/точки инжекта куда угодно и это практически не будет влиять на производительность. А если и надо заменять, то используют копипаст этого блока, и это не является проблемой. Т.к. для такого большого продукта как IDEA эти небольшие блоки меняются очень редко. Это десктоп приложение, и там приемлемы совсем другие компромиссы.
То же самое нельзя сделать с пхп. В результате будет минимум 2 из 3: тормоз, куча магии или нечитабельный код (и это даже в сравнении с aop).
По идее все можно решить добавить точки инжекта во все более менее критические точки приложения. Но тогда этих точек будут тысячи. И это будет сказываться на читаемости такого кода.
Проблема в том что ну очень часто заказчик хочет изменить совсем немного в какой-то небольшой части бизнес логики и он совсем не хочет каждый раз править код вручную после обновления основного приложения, особенно когда приложение платное. Т.е. напрямую изменить код вообще не составляет проблем - это реально просто и быстро. Но клиентам нужны дальнейшие обновления основного продукта. Если брать более низкий уровень и к примеру если используется кверибилдер, то надо немного изменить запрос перед выполнением, и тогда во всех местах где генерируется запросы надо вставлять точки инжекта, для возможности модификации этих запросов. Аналогично с обращением к сторонним апи и т.д. Т.е. хуки надо ставить везде и в большой количестве.
Это просто статистика, т.к. постоянно есть спрос на модификации готовых решений.
Я знаю что мало программистов напрямую общаются с заказчиками, и что здесь на форуме практически нет программистов связанных с модификацией/интеграцией готовых решений. Потому вопросы не совсем ложатся на стандартные практики. Когда пишется свое приложение для него тупо писать расширение, если можно (а вообще и нужно) просто исправить основной код. Я полностью поддерживаю что для разработки обычных приложений aop нафиг не сдалось (учитывая сложность тестирования и сложность поддержки).
Но речь идет о модульной и полностью расширяемой системе, где не хотелось бы писать точки инжекта мидлварей в любых более менее значимых местах (просто их будет слишком уж много). В том же ксенфоро и мадженто aop используется именно для композиции (хотя и реализовано это все через наследование), а не для aop как такового. И в них все так же есть и обычные события/хуки в тех местах где aop излишне.
p.s. когда говорю об aop я не имею ввиду именно реализацию go-aop, а имею ввиду сам принцип.
То же самое нельзя сделать с пхп. В результате будет минимум 2 из 3: тормоз, куча магии или нечитабельный код (и это даже в сравнении с aop).
По идее все можно решить добавить точки инжекта во все более менее критические точки приложения. Но тогда этих точек будут тысячи. И это будет сказываться на читаемости такого кода.
Проблема в том что ну очень часто заказчик хочет изменить совсем немного в какой-то небольшой части бизнес логики и он совсем не хочет каждый раз править код вручную после обновления основного приложения, особенно когда приложение платное. Т.е. напрямую изменить код вообще не составляет проблем - это реально просто и быстро. Но клиентам нужны дальнейшие обновления основного продукта. Если брать более низкий уровень и к примеру если используется кверибилдер, то надо немного изменить запрос перед выполнением, и тогда во всех местах где генерируется запросы надо вставлять точки инжекта, для возможности модификации этих запросов. Аналогично с обращением к сторонним апи и т.д. Т.е. хуки надо ставить везде и в большой количестве.
Это просто статистика, т.к. постоянно есть спрос на модификации готовых решений.
Я знаю что мало программистов напрямую общаются с заказчиками, и что здесь на форуме практически нет программистов связанных с модификацией/интеграцией готовых решений. Потому вопросы не совсем ложатся на стандартные практики. Когда пишется свое приложение для него тупо писать расширение, если можно (а вообще и нужно) просто исправить основной код. Я полностью поддерживаю что для разработки обычных приложений aop нафиг не сдалось (учитывая сложность тестирования и сложность поддержки).
Но речь идет о модульной и полностью расширяемой системе, где не хотелось бы писать точки инжекта мидлварей в любых более менее значимых местах (просто их будет слишком уж много). В том же ксенфоро и мадженто aop используется именно для композиции (хотя и реализовано это все через наследование), а не для aop как такового. И в них все так же есть и обычные события/хуки в тех местах где aop излишне.
p.s. когда говорю об aop я не имею ввиду именно реализацию go-aop, а имею ввиду сам принцип.
Последнее редактирование:
Это называется кастомизациями под отдельного заказчика. И это всегда сложно Ну и да.. специфика php в итоге сказывается на производительности. Я такую систему видел вживую и немного работал.. но она была на C#. Там все легко конфигурится и работает без тормозов.
Ну и да.. специфика php в итоге сказывается на производительности. Я такую систему видел вживую и немного работал.. но она была на C#. Там все легко конфигурится и работает без тормозов.
И как там было реализовано? Хуки на каждый чих?
Просто из того что я видел на пхп расширяемость в ксенфоро и мадженте самая адекватная, но и там и там основана на принципах aop, хотя конечно нигде в доках так не называется (типа просто отнаследуем виртуальный класс). Все остальное что видел это хуки/события и полный хардкор типа патчей на исходный код.
Последнее редактирование:
Я уже плохо помню, но мы вроде вообще без хуков и явного аоп обходились. Были объекты в стиле javabeans, которые конфигурировались через конфиги и передовались через цепочки, которые опять же конфигурировались через конфиги. Из-за всякой кривизны и непродуманности активно использовали паттерн декоратор, в который заворачивали эти объекты, когда надо было перееопределить что-то неконфигуриромое и хак с наследованием для доступа к протектит методам.
Я продвигал идею АОП, но не удалось убедить команду даже для кастомной реализации. Но тогда не было go-aop и речь шла о pecl расширении.
В любом случае, надо много шишек набить, чтобы сделать кучу точек входа и изменений, какой бы ты подход не юзал, всегда найдётся хотелка. У меня до сих пор глаз дёргается когда вижу в коде private, final, static
А по поводу AOP лучше дёрнуть самого Лисаченко, он кажись его в боевых проектах использует и не для cms-cmf со стабильным ядром.
Я продвигал идею АОП, но не удалось убедить команду даже для кастомной реализации. Но тогда не было go-aop и речь шла о pecl расширении.
В любом случае, надо много шишек набить, чтобы сделать кучу точек входа и изменений, какой бы ты подход не юзал, всегда найдётся хотелка. У меня до сих пор глаз дёргается когда вижу в коде private, final, static
А по поводу AOP лучше дёрнуть самого Лисаченко, он кажись его в боевых проектах использует и не для cms-cmf со стабильным ядром.