Зачем использовать прослушиватели событий над вызовами функций?
Я изучал слушателей событий в последнее время, и я думаю, что я, наконец, получил их. В основном это функции, которые вызываются методом другого объекта. Мой вопрос: зачем создавать прослушиватель событий, когда вызов функции будет работать нормально?
пример, я хочу позвонить игроку.display_health (), и когда это срабатывает, метод player.get_health () должен быть запущен и сохранен, чтобы display_health () имел к нему доступ. Почему я должен использовать прослушиватель событий просто вызов функции? Даже если display_health() были в другом объекте, это все равно не кажется мне проблемой.
Если у вас есть другой пример, который лучше подходит для использования, пожалуйста, дайте мне знать. Возможно, отдельные языки не получают от этого такой же пользы? (Javascript, PHP, ASP?)
4 ответов
вы не всегда можете контролировать код, который выполняет вызов. Или даже если вы, вы не хотите вводить зависимости в этот код. В таких случаях коду лучше запустить событие и разрешить коду, который вы контролируете, или коду, который должен иметь зависимость, прослушивать событие и действовать соответственно.
например, возможно вы создаете библиотеки, которая будет использоваться другими людьми. У них нет исходного кода или каким-то образом не может/не должен быть в состоянии изменить его (или не должны). В вашей документации указано, что конкретные события возникают при определенных обстоятельствах. Они, в свою очередь, могут реагировать на эти события.
или, возможно, у вас есть некоторые библиотеки доменов на вашем предприятии. Вы управляете ими и можете изменять их, но в архитектурном плане они обычно считаются работающими, поскольку они в настоящее время закодированы и не должны изменяться. (Не хотите нести раунд QA для повторной проверки обновленный код, код принадлежит другому отделу, и они не хотят, чтобы вы его меняли и т. д.) И вы находитесь в положении, когда вы хотите, чтобы этот код мог делать разные вещи в разных обстоятельствах/средах. Если этот код вызывает и событие, где это уместно, вы можете подключить свой код к нему (и/или соответственно поменять местами) без необходимости возиться с этим кодом.
просто несколько быстрых примеров, я уверен, что у других есть больше.
мой вопрос в том, зачем создавать прослушиватель событий при вызове функции будет работать нормально?
Что делать, если вы не знаете, какую функцию вы хотите вызвать?
возьмите классический пример, кнопку, на которую пользователь может нажать. Тот, кто пишет библиотеку, имеет идея какую функцию вы хотите вызвать при нажатии кнопки. Было бы также довольно запретительно, если бы каждая кнопка могла вызывать только одну и ту же функцию, когда она нажатый.
вместо этого, вы можете прикрепить обработчик событий к событию. Затем, когда событие запускается, кнопка может делать то, что ей нужно, без необходимости знать во время компиляции, какую именно функцию она должна вызывать.
Короче говоря, вы можете написать код без прослушивателя событий, но использование прослушивателя событий поможет другим использовать тот же код, что и библиотека.
даже с подробными ответами выше, у меня все еще были проблемы с пониманием фактической разницы между использованием контроллера / функций или прослушивателя событий.
одна из вещей, которая была опущена во всех этих ответах, заключается в том, что использование событий и прослушиватели событий пригодится, когда вы не хотите, чтобы соединить ваш код так близко. Каждая функция, класс и т. д. должны иметь единую цель.
Так сказать, вы получаете хит с запросом API от аутсайдера. В моем случае моя точная проблема понимания этой концепции заключалась в том, что я получаю вызовы API от Stripe Webhooks.
цель Stripe Webhooks: скажем, клиент тратит $ 10,000 на вашем сайте. Ваша стандартная процедура-Auth и Capture. Обновите БД, чтобы отразить их новый статус членства. В совершенном мире, и в случае нашей компании, 999/1000 раз, это идет совершенно. Либо их карта отклоняется на месте, либо оплата идет через. В обоих случаях мы отправляем им электронное письмо с уведомлением.
но как насчет времени 1/1000, когда пользователь платит, а полоса возвращает ошибку сбоя карты (что может быть несколько разных вещей)? В нашем случае мы отправляем их по электронной почте и сообщаем им, что биллинг не удался. Проблема, с которой мы столкнулись, заключается в том, что некоторые банки расследуют крупные сборы, которые возвращаются как ошибка, но затем через несколько минут банк санкционирует сборы, и оплата захваченный.
Так что же делать? Введите Полосу Webhooks. Stripe Webhooks попадет в конечную точку API, если произойдет что-то подобное. На самом деле, Stripe Webhooks может поразить ваш API любой и каждый раз, когда платеж не будет мгновенно аутентифицирован, захвачен или если клиент попросит вернуть деньги.
здесь слушатель событий пригодится. Полоса стреляет по сообщению с информацией о клиенте, а также типом Webhook. Теперь мы обработаем это, обновим базу данных и снимем их электронная почта успеха.
но почему бы просто не использовать стандартный маршрут и контроллер? Причина, по которой мы не просто используем стандартный маршрут и контроллер, заключается в том, что нам нужно либо изменить уже определенные функции, классы и т. д., либо создать новую серию классов, которые соединены вместе, например -> Stripe API Calls Received, Update DB, Send Email. Вместо того, чтобы связывать их близко друг к другу, мы используем прослушиватель событий, чтобы сначала принять вызов API, а затем ударить по каждому из них Классы, функции и т. д., оставив все отцепили.
Я искал везде, и я думаю, что документация Laravel объясняет это лучше всего. Я, наконец, понял, когда дал конкретный пример, и какова цель прослушивателя событий:
мероприятия являются отличным способом, чтобы отделить различные аспекты вашего приложения, так как одно событие может иметь несколько слушателей, которые не зависят друг от друга. Например, вы можете отправить уведомление Slack в пользователь каждый раз, когда заказ будет отправлен. Вместо того чтобы связывать код обработки заказов с кодом уведомления Slack, можно вызвать событие OrderShipped, которое слушатель может получить и преобразовать в уведомление Slack.