Czy zalecenie Resharpera uczynienia mojej prywatnej metody statyczną dobrą rekomendacją?

Question

Niedawno zauważyłem, że kiedy tworzę prywatne metody, które ustawiają kilka pól w przekazanych im obiektach, to Resharper podsuwa podpowiedź stwierdzającą, że metoda może być statyczna.

Oto bardzo uproszczony przykład tego, jaką metodę mogę mieć.

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

Kiedy mam taką metodę, Resharper zapewnia zalecenie, aby tę metodę można było ustawić statycznie.

Staram się unikać wprowadzania publicznych metod statycznych, ponieważ niszczą one próby jednostek ... ale nie jestem pewien, czy to samo dotyczy prywatnych metod.

Czy zalecenie Resharpera jest prawidłową najlepszą praktyką, czy też powinienem je wyłączyć?

Answer 1

Myślę, że to zdecydowanie najlepszy kandydat do statycznej metody. To nie zmienia żadnej z właściwości klasy za, pól, itp

Oto przykład:

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; 
} 

Ponadto, można zrobić to metodę rozszerzenia (co byłoby również statyczny):

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

Myślę, że tak; widząc, że metoda jest statyczna, wyraźnie wskazuje, że metoda powinna być interakcyjna z dowolnymi członkami instancji.

Wyobraź sobie, że debugowanie niestatycznej metody i realizacja instancji nie jest dotykana. Natychmiastowy zapach, a jeśli nie ma komentarza wyjaśniającego działanie funkcji, można oderwać się od prawdziwego problemu.

Answer 3

Zwykle zgadzam się z zaleceniem R #. Jest to metoda prywatna, więc (miejmy nadzieję) nie piszesz testów jednostkowych przeciwko niej. Uczynienie go statycznie oznacza, że ​​nie używa żadnych elementów instancji, co ułatwia kontrolę skutków ubocznych.

Answer 4

Na ryzyko brzmiące jak contrarian, muszę przyznać, że nie lubię mieszania metod statycznych metod instancji; i ogólnie nie lubię metod statycznych. Metody statyczne są trudne do przetestowania, trudne do przesłonięcia i trudne do utrzymania. Wolę trzymać wszystkie statyczne metody radzenia sobie z obiektami Foo w jednej klasie FooUtils - lub jeszcze lepiej w pojedynczym egzemplarzu klasy FooSomethingDoer.

Oczywiście metody statyczne mają sens w niektórych przypadkach - na przykład przy tworzeniu wspomnianych singletonów lub fabryk itp. Nie mówię, że wszystkie statyczne metody są wykonane z czystego zła; Wolę po prostu unikać ich, jeśli to możliwe.