2010-02-28 13 views

risposta

8

Questo è standard interface based programming.

Restituendo un IAsyncResult, il framework è libero di modificare l'implementazione interna in un secondo momento, senza interrompere il codice scritto sull'API del framework. Questo, in sostanza, ci dice, come sviluppatori, che non dovremmo preoccuparci di quale tipo di implementazione viene utilizzata, a condizione che l'interfaccia (IAsyncResult) sia soddisfatta.

Se, invece, è stata restituita la classe AsyncResult effettiva, la modifica a una classe diversa interromperà il codice esistente.

Inoltre, questo consente al framework di utilizzare la stessa interfaccia (IAsyncResult) in più posizioni, indipendentemente dal fatto che la classe AsyncResult sia appropriata o meno. Ne ho tratto vantaggio, personalmente, poiché ho creato le mie funzioni asincrone che restituiscono IAsyncResult supportato da una classe diversa, che memorizzava le informazioni che per me erano importanti. Ciò consente al mio codice di funzionare come il framework, senza limitarmi all'implementazione del framework.

+0

Ha senso. Grazie per il tuo aiuto – AspOnMyNet

+1

Il cielo ci aiuta se hanno bisogno di aggiungere un'altra funzione a quell'interfaccia, comunque. – Will

2

Perché non sempre restituisce un AsyncResult. La destinazione delegata può esistere in un altro contesto di esecuzione, una classe derivata da RealProxy può implementare un proxy per essa. I servizi remoti sarebbero un esempio. Restituire un tipo di interfaccia lo rende trasparente.

Problemi correlati