c# - tag - ¿Es malo no anular el registro de controladores de eventos?
propiedad tag c# (2)
Muchas personas parecen pensar que solo es importante darse de baja de los eventos si el editor va a sobrevivir al suscriptor. No me gusta ese enfoque. Un suscriptor de eventos que no se separa del editor crea algunas desagradables dependencias en el comportamiento de las entidades fuera del editor y el suscriptor. Si una referencia al editor se lleva a cabo más de lo esperado, eso mantendrá vivo al suscriptor, junto con cualquier objeto al que el suscriptor tenga referencia. Si una gran cantidad de objetos abandonados están interconectados por manejadores de eventos, pero no existe ninguna referencia en vivo para ninguno de ellos, todos los objetos pueden ser recogidos por el recolector de basura. Sin embargo, si alguien en alguna parte mantiene una referencia inesperada a uno de los objetos, eso puede evitar que se recolecte basura.
En mi humilde opinión, es mucho mejor ser proactivo en la eliminación de los controladores de eventos que abandonarlos y esperar que todo se limpie. A menos que uno pueda estar seguro de que no pueden existir referencias inesperadas al publicador, es probable que este enfoque funcione "mayormente", pero ocasione pérdidas de memoria ocasionales.
Si tengo una aplicación con solo unos pocos manejadores de eventos registrados (y los objetos que usan los eventos no se eliminan hasta que se cierre la aplicación), ¿realmente tengo que preocuparme por eliminar el registro de esos manejadores? La única buena razón que pude ver es que podría haber un poco de sobrecarga adicional si se disparan eventos de los que no te preocupes (es decir, tienes múltiples controladores registrados en un evento). ¿Hay alguna otra buena razón para hacerlo? ¿Alguien se encuentra con problemas importantes porque no cancelaron el registro de eventos?
Si tiene A publicando un evento y B suscribiéndose a un evento (el controlador), entonces es solo un problema no darse de baja si A va a vivir mucho más tiempo que B Básicamente, la suscripción al evento significa que A aún puede ver B , por lo que evitaría que se recolecte basura, y aún así activará eventos incluso si se olvidó (y tal vez Disposed() ).
Por ejemplo, este es un problema si A es un evento estático y tu aplicación se ejecuta durante un tiempo después de que B muera ...
Es importante tener en cuenta que uno podría preguntar lo siguiente:
si B vive mucho más tiempo que A, B evitará que A sea recolectada?
Y la respuesta a eso es "no". B no tiene referencia a A a través del evento; A se recogerá como siempre