c# - programacion - para que se usa el static

Ventajas de usar métodos estáticos privados

Question

Al crear una clase que tiene métodos privados internos, generalmente para reducir la duplicación de código, que no requiere el uso de ningún campo de instancia, ¿hay ventajas de rendimiento o memoria para declarar el método como estático?

Ejemplo:

foreach (XmlElement element in xmlDoc.DocumentElement.SelectNodes("sample"))
{
    string first = GetInnerXml(element, ".//first");
    string second = GetInnerXml(element, ".//second");
    string third = GetInnerXml(element, ".//third");
}

...

private static string GetInnerXml(XmlElement element, string nodeName)
{
    return GetInnerXml(element, nodeName, null);
}

private static string GetInnerXml(XmlElement element, string nodeName, string defaultValue)
{
    XmlNode node = element.SelectSingleNode(nodeName);
    return node == null ? defaultValue : node.InnerXml;
}

¿Hay alguna ventaja al declarar los métodos GetInnerXml () como estáticos? Sin respuestas de opinión, por favor, tengo una opinión.

Answer 1

Como ya se ha indicado, existen muchas ventajas para los métodos estáticos. Sin embargo; tenga en cuenta que vivirán en el montón durante la vida de la aplicación. Hace poco estuve un día rastreando una fuga de memoria en un servicio de Windows ... la fuga fue causada por métodos privados estáticos dentro de una clase que implementó IDisposable y fue llamada constantemente desde una instrucción de uso. Cada vez que se creó esta clase, la memoria estaba reservada en el montón para los métodos estáticos dentro de la clase. Desafortunadamente, cuando se eliminó la clase, la memoria para los métodos estáticos no se publicó. Esto causó que la huella de memoria de este servicio consumiera la memoria disponible del servidor en un par de días con resultados predecibles.

Answer 2

Cuando estoy escribiendo una clase, la mayoría de los métodos se clasifican en dos categorías:

• Métodos que usan / cambian el estado de la instancia actual.
• Métodos de ayuda que no usan / cambian el estado del objeto actual, pero me ayudan a calcular los valores que necesito en otro lugar.

Los métodos estáticos son útiles, porque con solo mirar su firma, usted sabe que la llamada no usa ni modifica el estado de la instancia actual.

Toma este ejemplo:

public class Library { private static Book findBook(List<Book> books, string title) { // code goes here } }

Si una instancia del estado de la biblioteca se estropea alguna vez, y estoy tratando de descubrir por qué, puedo descartar FindBook como el culpable, solo por su firma.

Intento comunicarme tanto como puedo con la firma de un método o función, y esta es una excelente manera de hacerlo.

Answer 3

Desde la página de reglas de FxCop en esto:

Después de marcar los métodos como estáticos, el compilador emitirá sitios de llamadas no virtuales para estos miembros. La emisión de sitios de llamadas no virtuales evitará una verificación en el tiempo de ejecución para cada llamada que asegure que el puntero del objeto actual no sea nulo. Esto puede generar una ganancia de rendimiento medible para el código sensible al rendimiento. En algunos casos, la falla al acceder a la instancia del objeto actual representa un problema de corrección.

Answer 4

Esto le obliga a recordar también declarar cualquier miembro de ámbito de clase que la función utilice como estática, lo que debería guardar la memoria de creación de esos elementos para cada instancia.

Answer 5

Prefiero que todos los métodos privados sean estáticos a menos que realmente no puedan ser. Preferiría mucho lo siguiente:

public class MyClass
{
    private readonly MyDependency _dependency;

    public MyClass(MyDependency dependency)
    {
        _dependency = dependency;
    }

    public int CalculateHardStuff()
    {
        var intermediate = StepOne(_dependency);
        return StepTwo(intermediate);
    }

    private static int StepOne(MyDependency dependency)
    {
        return dependency.GetFirst3Primes().Sum();
    }

    private static int StepTwo(int intermediate)
    {
        return (intermediate + 5)/4;
    }
}

public class MyDependency
{
    public IEnumerable<int> GetFirst3Primes()
    {
        yield return 2;
        yield return 3;
        yield return 5;
    }
}

sobre cada método de acceso al campo de instancia. ¿Por qué es esto? Debido a que a medida que este proceso de cálculo se vuelve más complejo y la clase termina con 15 métodos de ayuda privada, REALMENTE deseo poder sacarlos a una nueva clase que encapsula un subconjunto de los pasos de una manera semánticamente significativa.

Cuando MyClass obtiene más dependencias porque necesitamos iniciar sesión y también necesitamos notificar a un servicio web (disculpen los ejemplos del cliché), entonces es realmente útil ver qué métodos tienen qué dependencias.

Las herramientas como R # le permiten extraer una clase de un conjunto de métodos estáticos privados con unas pocas teclas. Intente hacerlo cuando todos los métodos de ayuda privada estén estrechamente relacionados con el campo de instancia y verá que puede ser un gran dolor de cabeza.

Answer 6

Sí, el compilador no necesita pasar el puntero implícito a static métodos static . Incluso si no lo usa en su método de instancia, todavía se está pasando.

Answer 7

Será un poco más rápido ya que no se aprobó este parámetro (aunque el costo de funcionamiento de llamar al método es probablemente mucho mayor que este ahorro).

Diría que la mejor razón que se me ocurre para los métodos estáticos privados es que significa que no se puede cambiar accidentalmente el objeto (ya que no hay este puntero).

Answer 8

Una llamada a un método estático genera una instrucción de llamada en el lenguaje intermedio de Microsoft (MSIL), mientras que una llamada a un método de instancia genera una instrucción callvirt, que también verifica las referencias de un objeto nulo. Sin embargo, la mayor parte del tiempo la diferencia de rendimiento entre los dos no es significativa.

src: MSDN - http://msdn.microsoft.com/en-us/library/79b3xss3(v=vs.110).aspx