He estado estudiando 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 qué utilizar los detectores de eventos sobre las llamadas a funciones?
Ejemplo, deseo llamar a player.display_health(), y cuando esto se active, el método player.get_health() debe activarse y almacenarse 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?)
La idea detrás de las bibliotecas de dominio sobre las que tengo control me dio una buena comprensión ya que la mayoría de las cosas con las que trabajo tienen control total. Entonces, dado que tengo control sobre eso, necesito hacer la pregunta opuesta, ¿hay alguna razón para NO usar escuchas de eventos sobre llamadas a funciones? – Organiccat
@ Organiccat: como antes, estoy seguro de que hay otras razones. Pero la razón más importante para mí sería el principio de inversión de dependencia. El código que responde al evento puede tener (o incluso ser) una dependencia que lógicamente no pertenece al código que provoca el evento. – David
Pensé en ello después, pero supongo que la duplicación de código también sería una buena razón para tener una función en lugar de un detector de eventos (especialmente cuando no se está codificando una biblioteca). – Organiccat