¿Por qué las clases estáticas no pueden tener destructores?
-
05-07-2019 - |
Pregunta
Dos partes de esto:
-
Si una clase estática puede tener un constructor estático, ¿por qué no puede tener un destructor estático?
-
¿Cuál es la mejor solución? Tengo una clase estática que administra un grupo de conexiones que son objetos COM, y debo asegurarme de que sus conexiones se cierren / liberen si algo explota en otra parte del programa.
Solución
En lugar de una clase estática, debe usar una clase normal con el patrón de singleton (es decir, mantener una instancia única de la clase, tal vez referenciada por una propiedad estática en la clase en sí). Entonces puede tener un destructor, o incluso mejor, una combinación de destructor y Disose método.
Por ejemplo, si ahora tiene:
static class MyClass
{
public static void MyMethod() {...}
}
//Using the class:
MyClass.MyMethod();
tendrías en su lugar:
class MyClass : IDisposable
{
public static MyClass()
{
Instance=new MyClass();
}
public static MyClass Instance {get; private set;}
public void MyMethod() {...}
public void Dispose()
{
//...
}
~MyClass()
{
//Your destructor goes here
}
}
//Using the class:
MyClass.Instance.MyMethod();
(Observe cómo se crea la instancia en el constructor estático, que se invoca la primera vez que se hace referencia a cualquiera de los miembros estáticos de la clase)
Otros consejos
-
Las clases estáticas no tienen destructores porque una clase estática nunca se destruye.
-
Si desea crear y destruir varias instancias de él, no debería ser estático. Haz que sea una clase completa.
-
Los destructores no deberían usarse para este propósito de todos modos. Utilice IDisposable / Disposición.
1. ¿Por qué? - un tipo no puede tener un constructor per se, como en la forma en que usted piensa normalmente de los constructores en instancias. En general, a veces se lo conoce como " inicializador estático " método pero Microsoft usa la terminología " tipo constructor " (y tiene restricciones especiales), pones código en él para iniciar el tipo / clase, si se tratara de un constructor de instancia, podría estar sobrecargado. Esta restricción estática en " tipo constructor " Esto se debe a que .NET CLR es responsable de cargar la plantilla de clase en el montón y no permite que se especifiquen los parámetros en esta circunstancia (porque nunca pasaría los argumentos). Debido a que, en el sentido más estricto, el programador no es responsable de hacer que se invoque el constructor de tipos, no tendría mucho sentido permitir que el programador codifique un destructor estático cuando está más en el dominio de CLR. Eventualmente, el CLR eliminará la plantilla de clase del montón, pero la vida útil de la plantilla de clase es más larga que sus instancias, por lo que no querría hacer nada de recursos intensivos en ella (por ejemplo, mantenga abierta una conexión de base de datos).
2. ¿Qué? - Singleton Si se encuentra en una circunstancia en la que cree que necesita abrir un recurso en la plantilla de clase y destruirlo después, puede considerar el Patrón de software Singleton para tener solo una instancia de esa clase y posiblemente también implementar el System.IDiposable para ayudar con la limpieza, además del destructor. (Veo que alguien ya me ha golpeado antes con el ejemplo de código IDisponible, así que terminaré mi solución aquí).
Una clase estática nunca se destruye. Se termina junto con el programa. Podría usar el patrón singleton como una implementación en lugar de usar una clase estática