DS
А зачем конкретные классы? Можно ведь интерфейсы сделать, будет без жёсткой привязки.
Интерфейс-маркер - не очень хорошая штука
Size: a a a
2020 May 15
NO
Хотя в любом случае пакет отдельный нужен... типа yii-lifecycle
NO
Почему маркер?
DS
Почему маркер?
Потому что пустой, это хак по сути, использование интерфейса не по назначению
NO
Я хочу допустим свой собственный класс событий замутить. А твоя схема мне навязывает жёстко наследование. Как-то не очень по архитектуре мне кажется...
NO
Ну почему пустой? Абстрактный класс не пустой же?
NO
Там будут публичные методы какие-то
NO
У интерфейса много назначений... И самое полезное, на мой взгляд, это проведение архитектурной границы между компонентами. Как раз обсуждаемый случай.
DS
Ну почему пустой? Абстрактный класс не пустой же?
Для большинства событий пустой
AM
Заставляет задуматься, а хорошая ли вообще идея события делать классами, а не строками...
DS
Заставляет задуматься, а хорошая ли вообще идея события делать классами, а не строками...
Ну дык Psr
NO
Хм... Так а зачем тогда нам классы нужны? Можно просто в конфиге дебаггера задать типа "on:app-shutdown" и потом триггерить событие "app-shutdown", как-то так организовать...
NO
Будет вообще без зависимостей тогда )
NO
А что есть PSR на события?
AM
Да, есть.
DS
AM
NO
Ну вот в нём кстати рекомендуется интерфейсы юзать для различения событий