¿Hay demasiados eventos?

public class Human 
{ 
    public void Run(){} 
    public void Jump(){} 
    public void Eat(){} 

    //Generalized approach 
    public EventHandler<HumanActivityProgressChanged> ActivityProgressChanged; 
    public EventHandler<HumanActivityCompleted> ActivityCompleted; 

    //Per-method approach 
    public EventHandler<HumanActivityProgressChanged> Running; 
    public EventHandler<HumanActivityCompleted> Ran; 

    public EventHandler<HumanActivityProgressChanged> Jumping; 
    public EventHandler<HumanActivityCompleted> Jumped; 

    public EventHandler<HumanActivityProgressChanged> Eating; 
    public EventHandler<HumanActivityCompleted> Ate; 
}

Tengo diferentes métodos que implementan el patrón Async basado en eventos. Estos métodos desencadenan un ProgressChanged eventargs y un Completed eventargs. Todos disparan los mismos eventargs (como se muestra en el código anterior).¿Hay demasiados eventos?

¿Tiene sentido proporcionar un evento para cada método asíncrono? ¿O solo proporciona un evento generalizado para todos los métodos asíncronos? ¿Hay demasiados eventos?

Fuente

2011-05-26 Ian

Ambos son válidos. Realmente depende de cuál es tu intención.

¿Va a esperar que un oyente desee escuchar todos los eventos y responder de manera similar? Ve por el evento generalizado.

Si está esperando un montón de oyentes dispares, cada uno interesado en diferentes aspectos, realizando tareas tremendamente diferentes en estos eventos, vaya por el segundo.

La idea detrás del diseño de la API no es imponer una determinada forma de uso en los clientes (rieles usuarios pueden estar en desacuerdo), pero le dará consejos fuertes en la forma en que el diseño se ..

Fuente

2011-05-26 08:47:25

El hecho de que todos los eventos tienen los mismos EventArgs es una indicación de que puede reemplazar estos eventos con un solo evento y pasar la actividad como una propiedad de los tipos HumanActivityProgressChanged y HumanActivityCompleted.

No existe ninguna ley que le indique que lo haga. Todo depende de lo que desea exponer y lo que los clientes esperarían/necesitarían.

Fuente

2011-05-26 08:48:04

Creo que sería una mala guía para refactorizar eventos a aquellos que comparten la misma firma; después de todo, en Windows.Forms, la clase Form tiene el mismo valor para 'Activated',' AutoSizeChanged', 'AutoValidateChanged'. .. –

No es una pauta de diseño. Es una "INDICACIÓN que PUEDE reemplazar". No estoy estableciendo una regla. Soy plenamente consciente de que muchos eventos comparten sus tipos EventArgs mientras que no deberían fusionarse. –

Es una cuestión de gusto, pero personalmente prefiero el primer enfoque. Por un lado, el mantenimiento será mucho más fácil. Y es simplemente más eficiente codificar de esa manera.

Fuente

2011-05-26 08:48:35

Excepto ... usted está cambiando la simplicidad de implementación en una clase ('Humano') por la complejidad del manejo de eventos en * cada * * único * consumidor de esos eventos. No es un gran intercambio. – Bevan

Estoy de acuerdo con usted en un punto, pero como se señaló en comentarios anteriores, depende en gran medida de la situación en cuestión. Un enfoque de patrón único rara vez es la mejor solución en mi opinión. –

¿Hay demasiados eventos?

Respuesta

Cuestiones relacionadas