2009-08-18 9 views
11

duplicados posibles:
Delegate Usage : Business Applications
Where do I use delegates?Mejores prácticas: ¿Cuándo debería usar un delegado en .NET?

Hola,

Soy nuevo en el concepto de un delegado en .NET - En realidad no he utilizado todavía y les Creo que probablemente estén ahí por una buena razón: ¿cuándo debería usar un delegado?

Los ejemplos son muy bienvenidos.

+0

Hay muchas preguntas similares, como esta: http://stackoverflow.com/questions/31497/where-do-i-use-delegates –

+0

O este: http://stackoverflow.com/questions/628803/delegate-usage-business-applications –

+0

O este: http://stackoverflow.com/questions/635015/when-would-i-use-a-delegate-in-asp-net –

Respuesta

4

Los delegados son útiles cuando necesita decirle a otra parte del código cómo para hacer algo. Los eventos son el ejemplo más simple: separando el evento (algo sucedió) de cómo para manejarlo. Otros ejemplos son algunas de las operaciones iterativas comunes, como un hallazgo personalizado:

List<Foo> foos = new List<Foo>(); 
foos.Find(delegate(Foo foo) 
    { 
     if(foo.CustomProperty.Contains("special value")) 
     { 
      return false; 
     } 
     return true; 
    }); 

Lo anterior es un ejemplo totalmente arbitraria, sino que hace que el punto de que se puede separar el qué (iteración y en funcionamiento un criterio de "encontrar") de la cómo (cómo determinar si se encuentra algo).

2

Events usan delegados entre bastidores.

Si usa eventos que ha usado delegados, pero solo con una sintaxis más agradable.

Básicamente, uno de sus usos es para devoluciones de llamada o programación basada en eventos.

2

Los delegados se utilizan para la programación controlada por eventos. Las mejores prácticas son a menudo sobre el código de desacoplamiento (o acoplamiento "suelto"). Al usar delegados, puede suscribir métodos a eventos, en lugar de hacer que X llame a Y si algo sucede, y luego Y llama a Z bajo ciertas condiciones, etc.

8

Los delegados proporcionan una forma de pasar el comportamiento como parámetro.

Los ejemplos comunes son los eventos y la programación asincrónica donde algo más que su objeto es responsable de llamar a su objeto. Proporciona ese evento a un delegado y ahora puede ejecutar el comportamiento asociado con ese delegado.

Esto también puede ser una técnica útil al implementar un algoritmo general. Ha habido ocasiones en las que estoy escribiendo varios métodos que son muy similares. Tal vez recorren el mismo conjunto de datos, pero realizan tareas ligeramente diferentes. Puedo pasar un delegado a una sola función para realizar esa tarea, luego llamar al delegado desde dentro del ciclo sobre los datos. De esta manera, no tengo que implementar el ciclo sobre los datos varias veces, solo tengo que escribir un nuevo código que haga cosas nuevas: el comportamiento común se captura de una manera común.

En respuesta al comentario:

La diferencia entre llamar el delegado de dentro del bucle y de llamar al método desde dentro del bucle es que el delegado es un parámetro a la función que contiene el bucle. Esto significa que esa función podría hacer cualquier cosa, no solo lo que se define dentro de un método en particular.Esa flexibilidad se puede y se ha aprovechado para suministrar algoritmos genéricos en bibliotecas completamente independientes de los detalles de con qué están trabajando los algoritmos. Linq es un buen ejemplo de la generalidad permitida a través de la flexibilidad de los delegados.

+0

Tu respuesta es un poco vaga para mí. ¿Cuál es la diferencia entre llamar a un delegado desde el uso del bucle y llamar a un método simple desde ese bucle? –

2

Events and Callbacks en .NET guidelines lo explica muy bien.

En resumen, debe preferir los eventos en API simples porque hay una gran compatibilidad con IDE y la mayoría de los desarrolladores se sienten cómodos con los eventos. Sin embargo, si necesita que el usuario proporcione el código que se ejecutará, debe considerar el uso de delegados o miembros virtuales. Las devoluciones de llamadas son menos efectivas, pero si usa delegados como Action y Func, permite lambdas.

3

Además, recomendaría utilizar tipos de delegados genéricos en lugar de crear los suyos propios. Ejemplos a continuación:

EventHandler< TEventArgs>
Func< TResult>
Func< T1, T2, TResult>
Func etc ...
Action< T1>
Action< T1, T2>
Acción etc ...

+1

Aaron: ese es un buen punto. Las Directrices de diseño del marco ahora indican que debe evitar la creación de delegados personalizados: http://blogs.msdn.com/brada/archive/2009/01/26/framework-design-guidelines-avoiding-custom-delegates.aspx – RichardOD

1
caso

Ejemplo: un único recurso está siendo utilizado por varios objetos . El recurso necesita una devolución de llamada asíncrona a estos objetos, pero la naturaleza del recurso exige que solo una solicitud esté activa en un momento dado, y esa solicitud está vinculada a un objeto particular. Debido a la arquitectura, no quiero pasar los objetos al recurso, así que, en su lugar, envío el recurso a un delegado de cada objeto y almaceno estos delegados junto con los identificadores de objetos. Cuando se realiza una solicitud, puedo buscar el identificador de objeto correspondiente y llamar a su delegado específico.

Originalmente lo implementé con un evento, pero como el evento no podía ser "dirigido" a un objeto en particular, tenía problemas. No estoy seguro de que esta sea la mejor práctica, pero parece funcionar bien para mí.

Cuestiones relacionadas