21
Esiste uno schema di progettazione che si occupa del meccanismo di callback?Esiste uno schema di progettazione che si occupa del meccanismo di callback?
A
risposta
19
Questo sarebbe il Observer Pattern - Da Wikipedia
Il pattern Observer (un sottoinsieme del asincrono pubblicazione/sottoscrizione modello) è un design pattern software in cui un oggetto, chiamato soggetto, mantiene un elenco delle sue dipendenze , chiamate osservatori, e notifica automaticamente le eventuali modifiche allo stato , in genere chiamando uno dei loro metodi . Viene principalmente utilizzato per implementare sistemi di gestione eventi distribuiti .
9
callback è una forma strategia di design pattern
+1
Concordo sul fatto che la strategia sia un'analogia migliore di Observer. Per me una richiamata sarebbe un puntatore a funzione o una chiusura. Poiché tali costrutti non sono disponibili in tutte le lingue, una strategia è l'approssimazione dell'armadio. A seconda del tuo punto di vista, hai la (mis) fortuna di dover creare le varie interfacce richieste dal tuo modello di scelta. – Patrick
7
Diversi. Scopri http://people.bu.edu/azs/teaching/cs108/2006fall/callback_pattern.pdf, e le seguenti: Modello
Observer Pattern: http://en.wikipedia.org/wiki/Observer_pattern
modello di strategia: http://en.wikipedia.org/wiki/Strategy_pattern
la più appropriata dipenderà la situazione. Quale linguaggio di programmazione vuoi utilizzare e cosa vuoi fare esattamente?
0
Viene in mente il modello di osservazione.
Un oggetto (suscriber) può essere assegnato a un altro oggetto (editore). Quando l'editore cambia o viene aggiornato, può notificare a tutti i suoi sostenitori.
A seconda della lingua utilizzata, è possibile specificare una funzione che deve essere richiamata nelle notifiche.
http://en.wikipedia.org/wiki/Observer_pattern
È ben descritto Design Patterns: Elements of Reusable Object-Oriented Software [Gang of Four]
4
External polymorphism - Un oggetto ha un riferimento ad un altro oggetto e una funzione da richiamare su tale oggetto. Può essere visto come un singolo tipo, quindi puoi combinare oggetti e funzioni per chiamare l'evento. I delegati sono un esempio di questo modello. Questo è più di un approccio in stile C#.
Observer pattern - Si utilizza un'interfaccia/classe base che un oggetto può implementare e registrare questa interfaccia per un evento. Più di un approccio in stile Java.
Controllare la risposta che ho postato qui per una soluzione di C++ per i delegati/polimorfismo esterno: raw function pointer from a bound method
15
Dipende da come viene utilizzato il callback.
Gli schemi di progettazione riguardano la comunicazione delle proprie intenzioni.
Se si desidera consentire a uno o più callback di essere registrati e possono essere chiamati come notifica "ad un certo punto nel futuro", si sta parlando di Observer. Inoltre, l'effettiva invocazione del callback in questo caso è solitamente "opzionale" o innescata in base ad alcuni stimoli. (I callback possono o non possono mai essere chiamati)
Se si intendesse passare "qualcosa da fare", e questo viene fatto nel metodo (o è usato per "fare qualcosa" durante un processo successivo) stai parlando di strategia. Inoltre, normalmente si verifica l'invocazione.
Nota che lo stesso codice esatto potrebbe essere: è davvero su come stai pensando al problema e su come vuoi che gli altri ci pensino.
+0
Questa risposta mi piace di più –
1
La tua domanda è molto generica e la risposta più generale che riesco a pensare è quella di usare il polimorfismo quando hai un problema che richiede un callback.
Il polimorfismo consente di specificare un contratto software sotto forma di un'interfaccia (o una classe astratta) su come deve essere utilizzato il callback. Quindi i clienti sono liberi di scegliere qualsiasi implementazione dell'interfaccia che ritengono appropriata per il loro scopo.
Se è consigliabile utilizzare lo stato, la strategia, il modello di osservatore o qualcosa di completamente diverso dipende molto dalle circostanze.
0
Sono d'accordo anche con gli altri poster sul pattern Observer. È specificamente progettato per questo scopo.
1
Una buona descrizione del modello è Service Callback design pattern. Fa parte di un catalogo di modelli SOA, ma il modello descritto può essere utilizzato con componenti generici che non sono servizi SOA.
Un altro modello correlato è lo Return Address pattern descritto nel libro classico "Modelli di integrazione aziendale" di Hohpe e Woolf.
Josuttis parla anche di richiamata nel suo libro "SOA in Practice". Lo chiama lo Request/Callback message exchange pattern.
Il pattern Observer è simile al modello publish-subscribe, non callback. Per una volta, i moduli Observer non vengono "richiamati" dopo aver chiamato il modulo Observable. The Observable chiama gli Observers per notificare loro cambiamenti di stato. –