Un oggetto punta alla sua descrizione di classe. La descrizione di classe punta a tutti i metodi dinamicamente linkati applicabili all'oggetto. Sembra quindi che potrebbe essere capaci di chiedere ad un oggetto se può rispondere ad un metodo in particolare.
Da un certo punto di vista questo è una misura di salvaguarda, dato un oggetto dubbio possiamo controllare a run time se siamo davvero in grado di applicare ad esso un metodo specifico. Se non controllassimo, il selettore del metodo controllerà certamente e interromperà il nostro programma se l'oggetto non è in grado di rispondere, ossia se la descrizione di classe dell'oggetto non contiene il metodo.
Perchè dobbiamo saperlo? Se siamo fortunati un metodo può essere applicato senza condizioni ad un oggetto che non sa nulla di esso, di conseguenza, non vi è la necessità di controllare. Tuttavia, se non fa differenza per il nostro algoritmo se il metodo viene o meno applicato, essere in grado di chiedere rende più utile l'interfaccia.
C'è da valutare il contesto delle funzioni di callback. Per esempio, se siamo capaci di maneggiare una finestra su un display, alcuni abitanti della finestra potrebbero voler essere informati quando vengono coperti o mostrati, cambiati in dimensione od eliminati. Possiamo informare il nostro client chiamando una funzione sulla quale abbiamo trovato un accordo: il client ci ha dato il nome di una funzione da chiamare per un particolare evento oppure ci siamo accordati su un nome specifico di una funzione.
Registrare una funzione di callback, la prima tecnica, sembra essere l'approccio più flessibile. Un client registra le funzioni solo per quegli eventi che sono importanti dal suo punto di vista. Client diversi possono usare differenti insiemi di funzioni di callbacks e non vi è la necessità di osservare un comune name space. L'ansi C ad oggi usa qualche funzione di callback: bsearch() e qsort() ricevono le funzioni di confronto relative a quelle per cui cercano od ordinano e atexit() registra le funzioni da chiamare prima che un programma termina l'esecuzione.
Accordarsi su un nome specifico di una funzione sembra ancora più facile: un riconoscitore generato da lex chiamerà una funzione yywrap() alla fine di un file di input e continuerà l'analisi se questa funzione non restituisce 0. Ovviamente, ciò è poco pratico se abbiamo bisogno di più di una funzione di questo tipo in un programma. Se bsearch() avrà una funzione di contronto chiamata cmp, sarà molto meno flessibile.