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

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

К.О.
Партнер клуба
Ну тогда

PHP:
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 (или какой-нибудь фабрики), но это мы не инверсию контроля используем, а инверсию зависимостей для достижений той же цели.
 
Сверху