Ho appena letto la domanda quali sono i framework callback? , dove cita il richiedente Quanto segue da Effective Java:
The disadvantages of wrapper classes are few. One caveat is that wrapper classes are not suited for use in callback frameworks, wherein objects pass selfreferences to other objects for subsequent invocations (“callbacks”).
Quindi sono curioso, perché le classi wrapper non sono adatte all'uso nei framework di callback? E puoi fornire un esempio di quale sia il problema?
La prossima linea di Java efficace è utile per chiarire il problema:
"Because a wrapped object doesn't know of its wrapper, it passes a reference to itself(this) and callbacks elude the wrapper. This is known as the SELF problem [Lieberman86]."
Sembra una cosa banale assicurarsi che tutti i riferimenti a un oggetto siano tramite il suo wrapper, ma i wrapper vengono generalmente iniettati quando si presenta la necessità e il loro design (il loro intero scopo di essere) è di fornire un low attrito per aggiungere più funzionalità a una classe esistente. Questo porta a bug sottili, come il wrapper che manca l'evento. Oppure il wrapper e l'oggetto avvolto che si registrano entrambi per gli stessi eventi, con conseguente duplicazione dell'elaborazione e potenziali problemi di concorrenza. Se non si conosce (non si dispone del codice sorgente) in cui sono registrati i callback, potrebbe essere impossibile aggirare il problema. Inoltre, i wrapper si basano su principi di composizione "puri" e i framework callback forzano un design "sporco" del wrapper.
Leggi altre domande sui tag java frameworks event-programming