Comments 6
event driven architecture хорош для статической типизации, т.к. уменьшает зависимости
а зачем это тута?
Буду рад увидеть продолжение или примеры из реальной жизни, где события особенно выручают. Всё-таки грамотное использование EventDispatcher — это про то, чтобы не запутаться в зависимостях и сохранить архитектуру при росте проекта.
Несмотря на кажущуюся мощь, под капотом вызов всех слушателей происходит весьма примитивным способом:
foreach ($listeners as $listener) {
if ($stoppable && $event->isPropagationStopped()) {
break;
}
$listener($event, $eventName, $this);
}И если вдруг какой-то из слушателей умрёт в процессе выполнения, то остальные не дождутся своей очереди. Получаем весьма странную архитектуру: можно закодить 100500 слушателей, но нет никакой гарантии что все они отработают. Даже логов не останется.
Если отбросить свисто-перделку приоритета, то подобные события вполне можно реализовать всего одной глобальной функцией:
function Events(string$event,mixed$listener=null):?\Closure
{static$storage=[];
if($listener instanceof \Closure)
{
$storage[$event][]=$listener;
return function()use(&$storage,$event,$listener){
$storage[$event]=array_filter($storage[$event],fn($item)=>$item!==$listener);
};
}
foreach(($storage[$event] ?? []) as $item)
if(false===$item($listener))
break;
return null;
}
Events('event',fn($data)=>print('Event 1:'.$data));
$cancel2=Events('event',fn($data)=>!print('Event 2:'.$data));
Events('event',fn($data)=>print('Event 3:'.$data));
Events('event','foo');
$cancel2();
Events('event','bar');И чем оно хуже?
И чем оно хуже?
Надругательство над PSR-12 и принципом единственной ответственности.
Не ООП подход, который не подойдёт для использования в ООП фреймворках.
$listener иногда слушатель, а иногда - данные для слушателя.
Нет stopPropagation.
Нет возможности использовать подписчиков (только слушатели).
В целом код запутанный, разбираться в логике тяжело.
Я бы не хотел работать в проекте, где код пишут таким образом.
Как работает EventDispatcher в Symfony