2010-01-15 31 views

risposta

10

In genere una "richiamata" è sotto il controllo del processo di rilevamento. Quindi si dice a un manager della GUI "chiama myaction quando si preme questo pulsante" e il gestore della GUI chiama l'azione quando si preme il pulsante.

I gestori di eventi invece operano a un livello rimosso. Il gestore della GUI è configurato per inviare messaggi a un gestore di eventi. Dì a un gestore di eventi che i pulsanti push sono gestiti dal programma myaction. Quando il pulsante viene premuto, il gestore della GUI mette un messaggio sui gestori di eventi in coda e ottiene la gestione della GUI, il gestore di eventi raccoglie il messaggio dalla coda, vede che è un pulsante, avvia il programma myaction e passa a gestire il prossimo evento. Di solito il programma myaction verrà eseguito come thread indipendente o addirittura separato.

Mentre il modello "gestore di eventi" è più complesso, è molto più robusto e presenta meno probabilità di bloccarsi quando un'azione non riesce. Rende anche una GUI più reattiva.

+0

Questa risposta deve essere contrassegnata come accettata. –

26

Un gestore di eventi è un tipo di richiamata. Si chiama ogni volta che si verifica un evento. Il termine è solitamente usato in termini di interfacce utente in cui gli eventi sono cose come muovere il mouse, fare clic su qualcosa e così via.

+5

Quindi ci sono altri scenari in cui è possibile chiamare una richiamata? Oltre agli eventi? Puoi per favore dare un esempio di una di queste situazioni? –

+2

@ cletus, mi è piaciuto rispondere, ma potresti aggiungere alcuni esempi di cosa sia un gestore di eventi e cosa sia il callback. Capisco quello che hai detto .. ma una richiamata avviene sempre perché "succede qualcosa", che succede qualcosa 99,999999% (a mio modesto riconoscimento) per essere un evento, non userei altro termine, e quindi, altro significato. .. e lì prima di concludere che tecnicamente parlando sono la stessa cosa. Per favore aiutami a migliorare il mio riconoscimento. Grazie!! Saluti! :). Prova a pensare in questo modo ... Potresti enumerare altri tipi di callback che non appartengono a un evento specifico? – Victor

36

Un callback è la procedura che si passa come argomento a un'altra procedura. La procedura che riceve il parametro può chiamarla o condividerla in modo che altre procedure nel sistema possano chiamarla.

Un gestore di eventi è una procedura chiamata quando si verifica un evento. Può essere una richiamata.

-3

Il gestore eventi è un callback dal sistema.

0

Mi piace come tutte queste risposte differiscano l'una dall'altra.

Vorrei concludere da questo, è che da un punto di vista terminologico eventi e callback sono intercambiabili. Cosa significano in un linguaggio di programmazione specifico o in un framework e differiscono però, perché qualsiasi piattaforma tende a scegliere i loro termini preferiti.

+0

Non intercambiabile; piuttosto, un gestore di eventi è un tipo di callback.È vero, tuttavia, alcune volte le persone usano un tipo molto specifico di una cosa per riferirsi al tipo generale. Un kleenex è un fazzoletto, ma non diresti veramente che puoi usare le parole in modo intercambiabile, giusto? –

+0

Quindi, per favore Esteban ci illumina con esempi concreti di callback che non sono gestori di eventi. Perché tecnicamente parlando, nel variare l'aspetto semantico di base, la stessa cosa. Grazie e saluti :). – Victor

8

Callback (da Wikipedia): "codice eseguibile passato come argomento ad altro codice".
Gestore eventi (sempre da Wikipedia): "subroutine callback asincrona che gestisce gli input ricevuti in un programma".

Quale è il modo in cui l'ho sempre capito: un gestore di eventi è un tipo di callback molto specifico.

9

Questa domanda è molto vecchia ma ho trovato questo collegamento da MSDN molto interessante. Spero che qualcun altro che inciampa su questa domanda ottenga qualcosa da questo link.

+1

Link eccellente. Grazie. – Tilak

+2

Interessante. Per parafrasare l'articolo: un evento è come un tweet; chiunque può leggere e rispondere ad esso. Mentre un callback è come un messaggio di testo; solo le persone a cui le hai inviate possono leggere e rispondere ad esse. – shawnhcorey

1

La risposta di James Anderson è la più dettagliata. Espansione sulla sua risposta; La richiamata si riferisce a qualsiasi codice, che viene passato come argomento a un metodo, destinato a essere chiamato in seguito in modo asincrono. Tuttavia, un callback non definisce come dovrebbe essere implementato il processo di callback stesso. È qui che inizia la classificazione delle callback. Tradizionalmente, un processo di richiamata apparirebbe:

  • lo sviluppatore definisce un callback e lo passa su una funzione definita libreria (uno che sa cosa fare con la richiamata in modo che il processo chiamante o il processo di rilevamento può chiamare) per es nel nodo,

var server = require('http').createServer(function(req, res){/* your code */});

il createServer è la funzione definita biblioteca che assicura il processo di rilevamento viene a chiamare il callback corretto, che in questo caso è function(req, res){/* your code */}

  • durante il funzionamento, la il processo di rilevamento riceve la posizione diretta del callback (perché la funzione definita dalla libreria lo ha fatto per te) e lo chiama. Ciò significherebbe 2 cose:
    • gli sviluppatori della biblioteca sarebbe sempre bisogno di sapere come trattare con diversi processi di rilevazione, come ciascuno può avere un diverso modo di richiamare
    • e se la richiamata deve essere chiamato più volte , potrebbe funzionare il processo di rilevamento. Ad es. se il processo di rilevamento è un processo della GUI, è consigliabile che il thread della GUI venga eseguito con meno attività possibile, per un'esperienza GUI fluida.

Così comportato la necessità di implementare un meccanismo di richiamo, che ha risolto questi 2 problemi:

  • un processo esterno che definisce un punto concorrente per la funzione di libreria di registrare callback e per il processo di rilevamento per notificare quando devono essere richiamati questi callback registrati.
    • Ciò significava che gli sviluppatori di entrambi questi processi ora possono funzionare indipendentemente l'uno dall'altro, senza conoscersi veramente reciprocamente.
    • Questo processo esterno è diventato noto come loop di eventi (nel nodo, ad esempio). Il termine "evento" è semplicemente il processo di notifica del ciclo degli eventi tramite il processo di rilevamento e il callback registrato è diventato noto come gestore di eventi.
  • il processo esterno (o il ciclo di eventi) ha accodato gli eventi e li ha eseguiti, eliminando così il processo di rilevamento che ora poteva riprendere a ciò che stava facendo meglio.

Così per gli eventi che si sono verificati più volte, il ciclo degli eventi o gestori eventi diventato il modo di richiamate attuazione, mentre i callback originali sono ancora preferito per singoli eventi come non sono realmente TASKING di rivelazione processo e non è necessario avere il ciclo degli eventi per un solo evento in quanto non è efficiente.

  • Il nodo js codice sopra è un evento isolato (come la connessione al server per un client è un evento una tantum mentre ci possono essere molte risposte che sono implementati come gestori di eventi) ed è un esempio di semplice richiamata.
0

I meccanismi sottostanti sono simili, ma la semantica è diversa. Entrambi i callback e i gestori di eventi sono denominati in modo asincrono.

La funzione di callback viene generalmente passata esplicitamente da una routine del chiamante per richiedere alcune informazioni. Le informazioni vengono restituite un po 'di tempo dopo, passate come argomenti alla callback dal callee. In questo momento, la routine chiamante completa la sua attività. Spesso il callback è una chiusura, sintatticamente all'interno della routine chiamante e spesso non nominata (anonima). Potrebbe sembrare un po 'come il seguito, in javascript:

function caller() { 
    someLibrary.getMeSomething(arg1, arg2, function(returnedData) { 
     // this is the callback which will do something with returnedData 
    }); 
} 

Così il chiamato (someLibrary.getMeSomething) prova a funzione di callback anonima, e qualche tempo dopo questa funzione viene chiamata con il returnedData. Un callback è come un evento single-shot per un singolo ricevitore.

I gestori di eventi vengono anche richiamati, ma in genere vengono utilizzati per un periodo prolungato per più eventi, come clic del mouse, eventi di rete, ecc. Inoltre, più oggetti potrebbero essere interessati allo stesso evento. Per questi motivi, in genere si "sottoscrive" o "si registra" per gli eventi nel codice di installazione (come l'inizializzazione dell'oggetto) e il gestore di eventi è in genere un metodo denominato. Di solito anche, ogni tipo di evento è identificato come costante o stringa.

Così in Python potrebbe assomigliare:

class MyUIClass: 

    def __init__(self): 
     someUILib.register(someUILib.events.MOUSE_CLICK, self.my_mouse_click_handler); 

    def my_mouse_click_handler(self, eventInfo): 
     # do something with event 
     if eventInfo.x < 100: 
      print 'You clicked in the margin' 
3

Un altro aspetto di questo è che gli eventi descrivere qualcosa che è accaduto in passato, mentre un callback è spesso usato mentre qualcosa sta accadendo.

Quando un evento si attiva, ti viene detto che qualcosa è successo. Quando viene utilizzata una richiamata, ti viene chiesto di partecipare a qualcosa.

Una libreria o un framework potrebbe emettere eventi che consentono di sapere che qualcosa è successo. Un framework offre punti in cui è possibile collegare codice (forse come callback) in modo da poter partecipare attivamente a un processo.

Parte del problema è quell'evento, la richiamata si riferisce ai mcehanismi tecnici e ai processi più astratti.

+0

Ritengo che questa sia la migliore risposta. –

7

Eventi - Pensa a un server (dipendente) e cliente (capo). Un dipendente può avere molti capi. L'impiegato solleva l'evento quando finisce l'attività e i capi possono decidere di ascoltare o meno l'evento Employee. Il dipendente è l'editore e i capi sono abbonati.

Callback - Il capo ha chiesto specificamente al dipendente di eseguire un'operazione e alla fine del compito, il capo desidera essere informato. Il dipendente si assicurerà che quando l'attività è terminata, egli notifichi solo il Boss che ha richiesto, non necessario tutti i Boss. Il dipendente non notificherà al capo, se il lavoro parziale è fatto. Sarà solo dopo che tutto il lavoro è stato fatto. Solo un capo ha richiesto l'informazione e l'impiegato ha inviato solo la risposta a un capo.

Problemi correlati