events - pasar - ¿Por qué utilizar escuchas de eventos a través de llamadas a funciones?
javascript addeventlistener events (3)
Mi pregunta es, ¿por qué crear un detector de eventos cuando se llama a la función funcionará bien?
¿Qué sucede si no sabe a qué función desea llamar?
Tome el ejemplo clásico, un botón en el que el usuario puede hacer clic. Quien escribe la biblioteca no tiene idea de qué función desea llamar cuando se hace clic en el botón. También sería bastante prohibitivo si cada botón solo pudiera llamar a la misma función cuando se hace clic.
Por lo tanto, en su lugar, puede adjuntar un controlador de eventos al evento. Luego, cuando se desencadena el evento, el botón puede hacer lo que necesita, sin tener que saber en tiempo de compilación exactamente a qué función se supone que llama.
He estado estudiando los oyentes de eventos últimamente y creo que finalmente los he decepcionado. Básicamente, son funciones que se invocan en el método de otro objeto. Mi pregunta es, ¿por qué crear un detector de eventos cuando se llama a la función funcionará bien?
Por ejemplo, quiero llamar a player.display_health (), y cuando esto se active, el método player.get_health () debería ser disparado y almacenado para que display_health () tenga acceso a él. ¿Por qué debería usar un detector de eventos simplemente llamando a la función? Incluso si display_health () estuviera en otro objeto, esto todavía no parece ser un problema para mí.
Si tiene otro ejemplo que se adapte mejor al uso, hágamelo saber. Quizás algunos idiomas en particular no se benefician tanto de él. (Javascript, PHP, ASP?)
Es posible que no siempre controle el código que realiza la llamada. O incluso si lo es, no desea introducir dependencias en ese código. En casos como este, es mejor que el código active un evento y permita que el código que controle, o el código que debería tener la dependencia, escuche el evento y actúe en consecuencia.
Por ejemplo, tal vez esté creando una biblioteca que será utilizada por otras personas. No tienen el código fuente o de alguna manera no pueden / no pueden modificarlo (o no deberían). Su documentación establece que los eventos específicos se plantean en circunstancias específicas. Luego pueden, a su vez, responder a esos eventos.
O tal vez tenga algunas bibliotecas de dominio en su empresa. Usted los controla y puede modificarlos, pero desde el punto de vista arquitectónico generalmente se considera que funcionan tal como están codificados actualmente y no deben modificarse. (No desea incurrir en una ronda de control de calidad para volver a validar el código actualizado, el código pertenece a otro departamento y no quiere que lo cambie, etc.) Y está en la posición en que desea que código para poder hacer cosas diferentes en diferentes circunstancias / entornos. Si ese código aumenta y el evento es relevante, puede conectar su código (y / o cambiarlo en consecuencia) sin tener que meterse con ese código.
Solo un par de ejemplos rápidos, estoy seguro de que otros tienen más.
En resumen, puede escribir el código sin el oyente de eventos, pero utilizando el oyente de eventos ayuda a otros a usar el mismo código que la biblioteca.