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

[Yoskaldyr]

Были объекты в стиле javabeans, которые конфигурировались через конфиги и передовались через цепочки, которые опять же конфигурировались через конфиги. Из-за всякой кривизны и непродуманности активно использовали паттерн декоратор, в который заворачивали эти объекты, когда надо было перееопределить что-то неконфигуриромое и хак с наследованием для доступа к протектит методам.

так отож...
И чем лучше такие декораторы или прокси, того же aop (и пофиг как оно реализовано, через аннотациями или через конфиги, через pecl расширение, наследование или go-aop)?

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

В любом случае, надо много шишек набить, чтобы сделать кучу точек входа и изменений, какой бы ты подход не юзал, всегда найдётся хотелка.

Вот и я о чем же...

Просто знаю все косяки аоп, но вот как по другому сделать не представляю. Пересмотрел ну очень много коробочных продуктов с возможностью расширения, и везде расширение сделано значительно хуже чем в magento/xenforo

 

[grigori]

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

настроить PhpStorm.

это где ты нашел такую опцию, в какой версии?

 

[Yoskaldyr]

@grigori да просто топик как всегда начинался с одного а продолжился совсем другим.

это где ты нашел такую опцию, в какой версии?

Эта опция есть с момента появления подсказок для параметров, но настройку отображать все спрятали знатно:

 

[fixxxer]

AOP не добавляет ничего нового, это просто способ inversion of control. Инверсию можно сделать и безо всякого AOP.

Ты очень общими словами рассуждаешь, непонятно, что именно тебе надо.

 

[grigori]

надо смотреть на конкретную реализацию кода, по возможности без узкой специфики, смотреть задачу, и обсуждать предметно

 

[Yoskaldyr]

AOP не добавляет ничего нового, это просто способ inversion of control.

именно.

Инверсию можно сделать и безо всякого AOP.

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

например, есть базовый класс
\BaseVendor\Application\Entity

этот класс расширяется 2-я дополнениями AddOn1 и AddOn2

фабрика или именованный конструктор \BaseVendor\Application\Entity::create

возвращает объект класса \AddOn2Vendor\Application\Entity, который extends \AddOn1Vendor\Application\Entity, последний в свою очередь extends \BaseVendor\Application\Entity (т.е. цепочка наследования от \BaseVendor\Application\Entity).

Это чисто aop или просто вариант inversion of control?

И что считать AOP, только когда код, не предназначенный для расширения, расширяется магией или считать AOP все что похоже на это?

P.S. Может все имеющее отношение к AOP вынести в отдельную тему?

 

[fixxxer]

Описанное - это вариант inversion of control.

Честно говоря, если в проекте соблюдаются принципы SOLID, не вижу никакого смысла в дополнительных инструментах: inversion of control всегда доступен и так - просто подсунуть свою реализацию интерфейса где надо.

Для Entities, правда, вообще не понимаю, зачем это все. Если меняется бизнес-логика - тут никакая декомпозиция не поможет, смена бизнес логики за собой тянет изменения во всем bounded context.

 

[Yoskaldyr]

Описанное - это вариант inversion of control.

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

Для Entities, правда, вообще не понимаю, зачем это все

Это тупо пример. Когда что-то меняется - почти всегда расширяется сразу несколько классов. Но ентитис меняются часто (добавляются новые или модифицируются существующие поля)

 

[fixxxer]

Ну тогда

class Foo extends Base
{
     public function method() {
          doBefore();
          parent::method();
          doAfter();
     }
}

это тоже АОП, что ли? Не, инверсия как раз в том, что doBefore/doAfter не тут.

АОП временами полезно, в частных случаях (скажем, всякие штуки типа @Transactional или логирование), но пихать это везде - ну, не знаю, по большому счету АОП это такой оператор comefrom, нужны веские основания

Что касается полей, это в тебе говорит геттерно-сеттерная логика, навязанная популярными анемичными моделями.
Если делать SOLID во все поля, с честной инкапсуляцией, то совсем все иначе получается.

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

 

[AmdY]

АОП скорее прикрывает плохую архитектуру и служит хорошим костылём в неидеальном мире. Но завязываться на него в бизнес правилах - плохо, приведёт к тому же хаосу как хуки в wp, где изменение порядка вызовов плагинов, меняет конечный результат.

 

[Yoskaldyr]

Но завязываться на него в бизнес правилах - плохо, приведёт к тому же хаосу как хуки в wp, где изменение порядка вызовов плагинов, меняет конечный результат.

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

Просто я под AOP понимаю более глобально и именно как стиль программирования, а не как конкретную реализацию и стиль описания кода (aop это всетаки стиль написания кода, а не только аннотации и магия). Если брать классические реализации go-aop c аннотациами или варианты из java все что с магией - это конечно очень похоже на comefrom и такое дебажить "просто замечательно".

Но если брать авторесолвинг правильного наследника из цепочки наследования через DIC, исходя из декларативного конфига, то это уже не AOP по мнению @fixxxer, хотя для меня стиль программирования расширений будет тот же - код до и после с вызовом parent метода. Да конфигурация расширения немного разная но код расширения будет 1 в 1 с aop реализацией, разве что косметические правки в зависимости от aop реализации. Если так, тогда и xenforo и magento - не используют aop

P.S. Кстати тот-же go-aop умеет работать без аннотаций через декларативный конфиг, хотя дебажить результат все еще не сильно удобно.

 

[fixxxer]

Я рассуждаю по аналогии с DIP: как при Dependency Injection зависимости определяются извне, так и в AOP этакий "comefrom", определенный извне. В PHPDoc-ах это, или в декларативной конфигурации, или каким-то внешним кодом - не важно: точно так же, как и для DI не важно, будет у нас @Inject(Foo, Bar) перед конструктором, декларативный конфиг или код, конфигурирующий контейнер, важен только сам факт инверсии. С parent-методом это скорее аналогия с сервис-локатором - все в явном виде. Да, мы можем получить гибкость за счет DI (или какой-нибудь фабрики), но это мы не инверсию контроля используем, а инверсию зависимостей для достижений той же цели.

 

[Adelf]

BTW, https://wiki.php.net/rfc/object-initializer

 

[fixxxer]

Не примут. Слишком С++-но для PHP.

 

[AnrDaemon]

Примут, потому что идиотов слишком много развелось.