Perché utilizzare eventi personalizzati anziché chiamate dirette ai metodi?

Question

Sono nuovo alla programmazione e ho controllato molti tutorial di codifica di giochi. Ho notato che sulla maggior parte di essi usano eventi personalizzati per attivare i metodi invece di chiamare direttamente un metodo.

Qual è il ragionamento dietro questa pratica? Perché non stanno solo chiamando il metodo?

Ad esempio:

---

Abbiamo due oggetti: A e B. A ha il metodo A.methodA() che B deve utilizzare quando viene attivata la condizione X.

Perché implementare:

B invia un evento a A che racconta A per eseguire A.methodA()

Invece di:

B utilizza A.methodA()

Answer 1

Il motivo principale è la separazione degli interessi. Quando si usano eventi, la classe A non ha bisogno di sapere dell'esistenza della classe B (e viceversa).

Alcuni vantaggi di questo sono:

• Molto più facile unit testing (è possibile verificare Classe A senza classe B)
• meno possibilità di rompere il vostro codice quando si cambia di classe A o B
• Meno riferimenti ad altre classi nel codice, che riduce il rischio di perdite di memoria
• Codice pulitore
• Codice più flessibile/riutilizzabile (un gruppo di altre classi potrebbe tutti ascoltare/rispondere all'evento con fuori qualsiasi codice aggiuntivo nel tuo committente)

Answer 2

In genere nelle applicazioni più grandi che utilizzano eventi contribuirà ad astrarre tutto. Quando hai più di 15 classi e sono tutti eventi di ditpatching su un controller, è molto più facile capire cosa sta succedendo che leggere tutte le diverse parti del codice per tracciare le funzioni. L'uso di callback inizia a creare il codice spaghetti.

Tuttavia, le chiamate alle funzioni dirette verranno eseguite più rapidamente degli eventi.

Answer 3

Personalmente, uso eventi personalizzati semplicemente per la facilità d'uso. Posso fare in modo che una classe invii un evento quando succede qualcosa (diciamo che un'animazione finisce o si verifica un errore in un download) e qualsiasi numero di altre classi esegue un numero qualsiasi di altre funzioni in base a quell'evento. Inoltre, codice per la riusabilità. L'obiettivo di ogni classe è la completa indipendenza in modo che possa essere eseguito in qualsiasi progetto senza la necessità di altri pacchetti. Quindi, anziché avere una chiamata di classe a un metodo di un'altra classe, invio un evento dalla prima classe che la seconda classe ascolta e quindi esegue quel metodo. Poi, quando ho bisogno di quella prima lezione per un altro progetto, posso semplicemente copiarlo/incollarlo senza doverlo modificare e senza perdere alcuna funzionalità.

MODIFICA: Inoltre, vale la pena notare che a volte le persone fanno ciò che descrivono per evitare di dover passare in argomenti di eventi.

Supponiamo che tu abbia un pulsante sul palco e devi poterlo fare clic, ma devi anche essere in grado di chiamare manualmente quel metodo. Alcune persone non si rendono conto che è possibile passare un evento nullo e avere solo il metodo singolo. Oppure si può impostare come un argomento di default null, vedere sotto:

private function onClickHandler(e:MouseEvent = null):void{ 
    //as long as you never reference "e" within this method, this method can be used both for MouseEvent listeners and manually calling it elsewhere in the code 
} 

Questa tecnica può aiutare a evitare di avere un gestore di eventi che chiama solo un altro metodo e nient'altro. A questo punto della mia programmazione, ogni singolo gestore di eventi AS3 che scrivo imposta l'argomento dell'evento su null per impostazione predefinita. Rende solo le cose più facili in seguito.

Answer 4

You might want to read this.

nota e anche utilizzando il metodo di callback consente di passare i parametri ad esso direttamente e non attraverso un modello di evento personalizzato.

Answer 5

Ho creato il mio sistema di invio di eventi molto semplificato. Il modello di eventi AS è molto potente, ma nel 99% delle situazioni non hai bisogno di quella potenza. Una semplice richiamata con parametri attivati ​​come evento è più che sufficiente. È ancora possibile mantenere la versatilità da un modello di eventi, ma non è necessario scrivere troppe righe di codice per, diciamo, un semplice pulsante. Posso installare un semplice evento come questo:

Buttonizer.autoButton(_buttQuit, this, "onPress"); 
public function onPressQuit(c:Sprite) { 
// Execution goes here 
} 

È possibile costruire il proprio modello di eventi, che renderà la vita più semplice, e il codice molto più conciso.