¿La recomendación de Resharper es hacer que mi método privado sea una buena recomendación?

Question

Recientemente he notado que cuando creo métodos privados que establecen algunos campos en los objetos que se les pasan, Resharper pone una pista que indica que el método puede estar estático.

Aquí hay un ejemplo muy simplificado del tipo de método que podría tener.

private void MakeStatusTheSame(MyClass mc, MySecondClass msc) 
{ 
    mc.Status = msc.Status; 
} 

Cuando tengo un método como este, Resharper proporciona una recomendación de que el método se puede hacer estático.

Trato de evitar que los métodos públicos permanezcan estáticos, ya que destruyen las pruebas unitarias ... pero no estoy seguro de que lo mismo se aplique a los métodos privados.

¿Es la recomendación de Resharper una buena práctica válida o debería simplemente desactivarla?

Answer 1

Creo que definitivamente es un candidato principal para un método estático. No es de cambiar cualquiera de las propiedades de la clase, campos, etc.

He aquí un ejemplo:

class MyClass 
{ 
    public static void MakeStatusTheSame(MyClass mc, MySecondClass msc) 
    { 
    mc.status = msc.status; 
    } 

    private void MakeStatusTheSame(MySecondClass msc) 
    { 
    this.status = msc.status; 
    } 

    private int status; 
} 

Además, se puede hacer que sea un método de extensión (que también sería estática):

public static class Extensions 
{ 
    public static MyClass MakeStatusTheSame(this MyClass mc, MySecondClass msc) 
    { 
    mc.status = msc.status 
    return mc; /* make the method chainable */ 
    } 
} 

Answer 2

Creo que sí; ver que un método es estático es una clara indicación de que el método debe estar no interactuando con los miembros de la instancia.

Imagine la depuración de un método no estático y la realización de la instancia no se está tocando. Hechizo instantáneo, y si no hay un comentario que explique lo que hace la función, podría distraerse del problema real.

Answer 3

Normalmente voy con la recomendación de R #. Es un método privado, así que (afortunadamente) no estás escribiendo pruebas unitarias en su contra. Hacerlo estático explícitamente establece que no utiliza ningún miembro de instancia, lo que facilita la inspección de los efectos secundarios.

Answer 4

A riesgo de sonar como un contrario, tengo que admitir que no me gusta mezclar métodos estáticos con métodos de instancia; y no me gustan los métodos estáticos en general. Los métodos estáticos son difíciles de probar, difíciles de anular y difíciles de mantener. Prefiero pegar todos los métodos estáticos para tratar con objetos Foo en una única clase FooUtils o, mejor aún, en una instancia singleton de una clase FooSomethingDoer.

Por supuesto, los métodos estáticos tienen mucho sentido en algunos casos, por ejemplo, al crear los singletons o fábricas antes mencionados, etc. No digo que todos los métodos estáticos estén hechos de puro mal; Solo prefiero errar del lado de evitarlos cuando sea posible.