¿Mi clase debe suscribirse a sus propios eventos públicos?

Question

Estoy usando C# 3.0. Siguiendo el patrón de eventos estándar que tengo:

public event EventHandler<EventArgs> SomeEventHappens; 

    protected virtual void OnSomeEventHappens(EventArgs e) 
    { 
     if (SomeEventHappens != null) 
     { 
      SomeEventHappens(this, e); 
     } 
    } 

    private object _someProperty; 

    public object SomeProperty 
    { 
     get 
     { 
      return _someProperty; 
     } 
     private set 
     { 
      if (_someProperty == value) 
      { 
       return; 
      } 
      OnSomeEventHappens(EventArgs.Empty); 
      _someProperty = value; 
     } 
    } 

Dentro de mi misma clase me gustaría tomar algunas acciones cuando SomeProperty cambios. La forma en que lo veo Tengo 3 alternativas:

1) Hacer cosas dentro de mi SomeProperty setter. Algo me frota en el camino equivocado al hacer esto, ya que trato de suscribirme a la filosofía de que todo debería hacer una cosa y hacerlo bien. Arrebatar cosas en un setter parece ir en contra de eso, o al menos tiene la propensión a.

2) Haz cosas en OnSomeEventHappens. De nuevo, parece ir un poco en contra de mantener esto en pedazos simples. Además, si se anula este método, podría perder funcionalidad si el implementador no llama al método base.

3) Haga que la clase se suscriba a SomeEventHappens. Para mí, esta parece ser la elección correcta en lo que respecta a la encapsulación, y parece bastante limpia. Nuevamente, posibles repercusiones si se anula el OnSomeEventHappens.

¿Tal vez hay algo más elegante? No puedo decidir entre la opción 2 y 3, y tengo curiosidad sobre cuáles son las mejores prácticas. Quizás el lugar más seguro esté en el establecimiento de la propiedad después de todo.

¿Pensamientos?

Actualización: Gracias por los buenos comentarios y respuestas a continuación. He aprendido que está "bien" tener una clase suscribirse a sus propios eventos, aunque en mi caso me inclino a no hacerlo debido a la sobrecarga. He pensado en el comportamiento de posibles usuarios de mis métodos virtuales y qué es exactamente lo que quiero que suceda.

En mi caso del mundo real, realmente no quiero que los eventos se levanten sin que se establezca la propiedad. Como las respuestas a continuación han guiado mi proceso de pensamiento, creo que puedo ir con la opción 1, debido a la menor sobrecarga, a la reducción del riesgo de un comportamiento inadecuado por parte de los herederos, y generalmente tiene más sentido para mí. ¡Gracias de nuevo!

Answer 1

Si llama SomeEventHappens y OnSomeEventHappens desde una ubicación común (el procedimiento de propiedad u otra función), entonces no tiene que preocuparse de que los overriders descuiden el evento. Preferiría anular una función en lugar de manejar eventos porque hay menos sobrecarga.

Answer 2

¿Va a siempre desea realizar esta acción, o puede que desee suscribirse y darse de baja? En este último caso, la opción 3 es claramente una buena idea.

¿Es la acción que desea tomar el tipo de acción que otra clase puede tomar? De nuevo, eso se inclinaría hacia la opción 3.

¿La acción que desea realizar forma parte intrínseca de la configuración de la propiedad? Si es así, la acción 1 puede ser aconsejable.

La opción 3 suena como un buen acercamiento "ligero" para mí.

Answer 3

En frameworks de objetos fuera de .NET, un objeto que se suscribe a sus propios eventos está mal visto principalmente porque tales cosas llevan a referencias circulares que podrían mantener el objeto vivo indefinidamente. Esto no es un problema en.NET, pero aún me parece "extraño" que un objeto se toque a sí mismo de esta manera.

Si una clase siempre necesita saber cuándo ocurren cambios en la propiedad, su mejor opción es hacer el método OnSomeEventHappens virtual y anularlo en las clases descendientes que necesitan la información adicional. Está bien poner código en el método de activación de eventos. El método de activación de eventos está allí precisamente para que todos los que quieran lanzar ese evento tengan una manera uniforme de hacerlo.

Si solo ocasionalmente necesita ser informado de cuándo cambia la propiedad, entonces supongo que sería apropiado suscribirse y cancelar la suscripción al evento.

Answer 4

Si posee el estado de su propio objeto, la captura de eventos me suena mal. Me gustaría ir con un método virtual por separado. No interfieras con tu evento y espera que los niños lo tomen. Tal vez esto sería algo así como:

private object _someProperty; 
    public object SomeProperty 
    { 
     get 
     { 
      return _someProperty; 
     } 
     private set 
     { 
      if (_someProperty != value) 
      { 
       OnSettingSomeProperty(_someProperty, value); 
       OnSomeEventHappens(EventArgs.Empty); 
       _someProperty = value; 
      } 
     } 
    } 

    protected virtual void OnSettingSomeProperty(object oldValue, object newValue) 
    { 
     // children can play here, validate and throw, etc. 
    }