Eliminar manipuladores en la eliminación del objeto

Question

Se me ocurren algunas formas complicadas de resolver esto, pero me parece que debería haber una solución mucho más elegante que las que ya se me ocurrieron.

¿Cuál es la forma más adecuada para que un objeto se limpie a sí mismo de todos sus controladores de eventos antes de ser eliminado? Es una pena que no se pueda enumerar el controlador de eventos.

En teoría, ¿se considera más correcto para el código agregar el controlador a un objeto para recordar eliminarlo que suponer que el objeto se limpiará antes de que salga del alcance?

Answer 1

En teoría, se considera que más correcta para el código de añadir el manejador a un objeto de recordar a quitarlo de asumir el objeto va a limpiar a sí misma antes de que salga fuera de alcance?

A la pregunta anterior, tendré que decir que sí. La teoría básica sobre los eventos es que el atacante del evento no debe ser responsable de administrar sus propios manejadores; quien haya agregado el evento debería hacer la limpieza.

Answer 2

Hay una manera de evitar este problema común con los eventos: WeakEvent pattern.

Answer 3

Los controladores de eventos son para mí la mayor amenaza para el consumo de memoria de una aplicación .NET, especialmente si comienza a usarla en un contexto de servidor web. Para mí, siempre es responsabilidad del objeto que se adjuntó a desensamblar. Un objeto adjunto debe tener siempre una duración de vida menor o igual que el objeto al que se adjunta, de lo contrario hay un problema con el diseño de los eventos, ya que no desea recibir notificaciones de cambios en objetos que ya no tienen ningún significado . Si su vida útil es igual, saldrán del alcance juntos y no es necesario que haga nada, si es más corto, entonces el objeto adjunto debe separarse. En una aplicación web básica, solo tiene 3 tipos de esperanza de vida, aplicación, sesión y página, y las reglas son fáciles de aplicar. En aplicaciones más complejas, esto requiere pensar un poco más.

Answer 4

En mis diseños soy bastante estricto en cuanto a la definición de los contratos como:

• cada adquisición de recursos debe estar emparejado con un comunicado de
• cada llamada para iniciar un servicio debe estar emparejado con un llamado a detener el servicio
• cada observador que se conecta a un sujeto debe separar
• y así sucesivamente

(dicho contrato No son inusuales, como que debe vincular el abrir y cerrar un archivo o emparejar llamadas nuevas/eliminar en idiomas que no emplean la recolección automática de basura.

Cada uno de estos contratos puede probarse en tiempo de ejecución hasta cierto punto. Por ejemplo, un observador que se separa más veces de las que tiene asociadas puede ser detectado e informado (afirmación o excepción según la situación).

Por lo tanto, su pregunta que:

En teoría, es que considera más correcta para el código de añadir el manejador a un objeto de recordar a quitarlo de asumir el objeto va a limpiar a sí misma antes de ir fuera del alcance?

Es perfecto. La respuesta es Sí, y no solo en teoría, sino también en la práctica. En mi opinión, estos contratos te ayudan a evitar errores radicales debajo de la alfombra.

Olvídate de este pensamiento y estarás en camino de crear un software realmente sólido.