Событие Laravel 5 — это посредник или наблюдатель?

Сегодня я обсуждал систему событий Laravel с другим разработчиком. Он упомянул, что диспетчер событий Laravel использует шаблон наблюдателя.

Я всегда думал, что он реализует шаблон посредника, поскольку ваши объекты всегда прослушивают/выдают события через объект диспетчера событий, но документ говорит, что это наблюдатель.

Event::listen('event.name', function ($foo, $bar) {
    //
});

Event::fire("event.name", []);

Разве это не модель посредника?


php design-patterns laravel-5 observers mediator
person Moon    schedule 15.02.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

У меня нет точного представления о том, что конкретно делает Laravel, и на самом деле, если документ говорит, что он построен на шаблоне наблюдателя, я бы поверил этому.

Однако ваш вопрос касается того, как выглядит код, и по моему опыту я могу легко узнать здесь наблюдателя по аналогии:

  • прослушивание будет похоже на подписку/присоединение Observer.
  • fire будет похоже на уведомление/обновление Observer.

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

person floppy12    schedule 15.02.2016
comment
@ floopy12 Но разве вы не получаете экземпляр объекта, а затем слушаете его, если это наблюдатель? В этом случае вы слушаете класс Event, а не интересующий вас объект. Наличие listen/fire не означает, что это наблюдатель. Посредник также может слушать/огонять. - person Moon; 16.02.2016
comment
@Moon На мой взгляд, единственное, что имеет значение, это то, что вы слушаете что-то еще, даже если это не объект, это означает, что вы каким-то образом заинтересованы. Шаблон Observer (или любой другой) не принадлежит ни к какому языку или парадигме. , это концептуальная идея для выражения проблемы и решения. Реализация должна быть настроена в соответствии с вашими конкретными потребностями. Здесь кажется, что это больше функциональный подход, когда вы слушаете событие и связываете с ним обратный вызов, чем классическая реализация ООП. - person floppy12; 16.02.2016
comment
@floopy12 // Это я полностью понимаю. Проблема в том, что эта имплантация также предполагает несколько свободную компиляцию, поскольку имя события может быть любым, а событие действует как посредник, независимо от того, слушаю ли я конкретное событие или нет. Я думаю, именно поэтому некоторые PHP-фреймворки называют его посредником, а Laravel — нет. - person Moon; 16.02.2016
comment
@Moon: Что касается слабой связи, то как в Mediator, так и в Observer, objA и objB не взаимодействуют напрямую (соответственно через Mediator или событие, даже если оно запускается из наблюдаемого объекта). Предоставленного кода недостаточно, чтобы понять, что Laravel на самом деле делает под капотом. Однако, учитывая, что посредник облегчает связь между двумя другими объектами (или более), где два субъекта здесь, если событие представляет посредника? Более того, будет ли событие подходящим названием для Медиатора? (Учитывая, что это приемлемое имя для Observable) - person floppy12; 16.02.2016
comment
@floopy12 // Не возражаю, но и не соглашаюсь. Насколько я понимаю книгу GOF, наблюдатели зависят друг от друга. Вам нужен экземпляр субъекта для прослушивания. Я понимаю, что имплантация меняется, но я действительно не думаю, что намерение должно измениться. В данном конкретном случае никто на самом деле не зависит друг от друга. Это просто в голове программиста. Думаю, я задал здесь неправильный вопрос, так как не будет конкретного ответа, а будут хорошие мнения. Я ценю ваши мысли. - person Moon; 16.02.2016
comment
@Moon: Я понимаю ваше недоумение, и мне будет трудно прояснить ситуацию. ИМХО, я вижу здесь Observable (событие или держатель события) и Observer (функция или держатель функции). Два объекта связаны строкой event.name вместо явного общения (функция вызова держателя события с аргументами foo и bar). Я думаю, намерения Наблюдателя полностью соблюдаются. Наоборот, Медиатор был бы третьим объектом, который, с одной стороны, получил бы Событие, а с другой стороны, вызвал бы функцию. - person floppy12; 16.02.2016
comment
@Moon: Что вас, безусловно, смущает, так это то, что связь между событием и обратным вызовом осуществляется строкой, а не конкретным объектом. Но это всего лишь способ добиться более слабосвязанного дизайна, используя общие аргументы вместо того, чтобы полагаться на объекты. Дополнительная информация о en.wikipedia.org/wiki/Loose_coupling — раздел Методы уменьшения связи - person floppy12; 16.02.2016