Jaki jest zysk z zadeklarowania metody jako statycznej

Nie ma tu pojęcia o optymalizacji.

A static metoda jest static, ponieważ jawnie deklarujesz, że metoda nie opiera się na żadnej instancji klasy zamkniętej tylko dlatego, że nie musi. Tak więc ostrzeżenie o zaćmieniu, jak podano w dokumentacji:

Po włączeniu, kompilator wyda błąd lub ostrzeżenie dla metod, które są prywatne lub końcowe i które odnoszą się tylko do statycznych członków.

Jeśli nie potrzebujesz żadnej zmiennej instancji, a twoja metoda jest prywatna (nie może być wywołana z zewnątrz) lub ostateczna (nie może być nadpisana), wtedy nie ma powodu, aby pozwolić, aby była to normalna metoda zamiast statycznej. Statyczna metoda jest z natury bezpieczniejsza nawet dlatego, że możesz robić z nią mniej rzeczy (nie potrzebuje żadnej instancji, nie masz żadnego implicit this object).

Nie mam informacji na temat wydajności, przypuszczam, że jest to co najwyżej nieznacznie lepsze, ponieważ kod nie musi wykonywać dynamicznej wysyłki w oparciu o Typ.

Jednak znacznie silniejszym argumentem przeciwko refaktoryzacji metod statycznych jest to, że obecnie używanie metod statycznych jest uważane za złą praktykę. Statyczne metody / zmienne nie integrują się dobrze z językiem zorientowanym obiektowo, a także trudno je poprawnie przetestować. Jest to powód, dla którego niektóre nowsze języki rezygnują z pojęcia statycznego metody / zmienne w ogóle, lub spróbuj internalizować je w języku w sposób, który lepiej gra z OO (np. obiekty w Scali).

W większości przypadków potrzebujesz metod statycznych do implementacji funkcji, które używają tylko parametrów jako danych wejściowych i wytwarzają dane wyjściowe za pomocą tego (np. funkcje narzędziowe/pomocnicze) we współczesnych językach istnieje koncepcja funkcji pierwszej klasy, która na to pozwala, więc statyczna nie jest potrzebna. Java 8 będzie miała wbudowane wyrażenia lambda, więc przechodzimy do tego kierunek już.

1. deklarowanie metody static daje niewielkie korzyści wydajnościowe, ale co bardziej użyteczne, pozwala używać jej bez konieczności posiadania instancji obiektu pod ręką(pomyśl na przykład o metodzie fabrycznej lub uzyskaniu Singletona). Służy również celowi dokumentacyjnemu, polegającemu na określeniu charakteru metody. Ten cel dokumentacyjny nie powinien być ignorowany, ponieważ daje natychmiastową wskazówkę na temat charakteru metody czytelnikom kodu i użytkownikom API, a także służy jako narzędzie do myślenie dla oryginalnego programisty-bycie wyraźnym co do zamierzonego znaczenia pomaga również myśleć prosto i produkować kod lepszej jakości(myślę, że bazując na moim osobistym doświadczeniu, ale ludzie są różni). Na przykład, logiczne i dlatego pożądane jest rozróżnienie między metodami operującymi na typie a metodami działającymi na instancji typu (jak zauważył Jon Skeet w komentarzu do pytania C# ).

Kolejnym przypadkiem użycia metod {[0] } jest naśladowanie interfejs programowania proceduralnego. Pomyśl o java.lang.System.println() klasy oraz metod i atrybutów w niej zawartych. Klasa java.lang.System jest używana jako przestrzeń nazw grupowania, a nie instancjonalny obiekt.

2. skąd Eclipse (lub jakikolwiek inny programowany lub inny rodzaj - biokompozytowej lub nie-biokompozytowej - jednostki) może wiedzieć na pewno, która metoda może być zadeklarowana jako statyczna? Nawet jeśli klasa bazowa nie ma dostępu do zmiennych instancji ani nie wywołuje niestatycznych metod, za pomocą mechanizmu dziedziczenie rzeczy mogą się zmienić. Tylko jeśli metoda nie może być nadpisana przez dziedziczenie podklasy, możemy ze 100% pewnością stwierdzić, że metoda naprawdę może być zadeklarowana static. Nadpisanie metody jest niemożliwe dokładnie w dwóch przypadkach bycia

1. private (Żadna podklasa nie może używać go bezpośrednio i nawet w zasadzie o nim nie wie), lub
2. final (nawet jeśli jest dostępna przez podklasę, nie ma możliwości zmiany metody, aby odwoływać się do danych instancji lub funkcje).

Stąd logika opcji Eclipse.

3. oryginalny plakat również pyta: "wskazując metodę jako statyczną, przypuszczam, że pokazuje, że nie używasz żadnych zmiennych instancji, dlatego można przenieść do klasy stylu utils? " to bardzo dobra uwaga. Czasami tego rodzaju zmiana projektu jest wskazywana przez Ostrzeżenie.

Jest to bardzo przydatna opcja, którą osobiście bym włączył, gdybym użył Eclipse i do programowania w Javie.

Zobacz odpowiedź Samuela na temat zmian zakresu metody. Myślę, że jest to główny aspekt statycznej metody.

Pytałeś też o wydajność:

Może być mały przyrost wydajności, ponieważ wywołanie statycznej metody nie wymaga ukrytego odniesienia "this" jako parametru.

Jednak ten wpływ na wydajność jest naprawdę niewielki. Dlatego chodzi o zakres.

Z wytycznych dotyczących wydajności Androida:

Preferuj statyczne niż wirtualne, jeśli nie potrzebujesz dostępu do obiektów fields, uczyń swoją metodę statyczną. Inwokacje będą wynosić około 15% -20% szybciej. Jest to również dobra praktyka, ponieważ można stwierdzić z metody podpis, że wywołanie metody nie może zmienić stanu obiektu.

Http://developer.android.com/training/articles/perf-tips.html#PreferStatic

Cóż, dokumentacja zaćmienia mówi o tym ostrzeżeniu:

Metoda może być statyczna

Po włączeniu kompilator wyda błąd lub ostrzeżenie dla metody, które są prywatne lub ostateczne i które odnoszą się tylko do statycznych członkowie

Myślę, że to wszystko mówi. Jeśli metoda jest prywatna i ostateczna i odnosi się tylko do elementów statycznych, metoda ta może być równie dobrze zadeklarowana jako statyczna i przez to, należy zauważyć, że zamierzamy tylko uzyskać dostęp do statycznych treści z niego.

Szczerze mówiąc, nie wydaje mi się, aby był to jakiś inny tajemniczy powód.

Brakowało mi kilku liczb na różnice prędkości. Więc próbowałem je porównywać, co okazało się nie takie proste: pętla Javy staje się wolniejsza po niektórych uruchomieniach / JIT ' s fault?

W końcu użyłem Calipera i wyniki są takie same jak ręczne przeprowadzanie testów:

Nie ma mierzalnej różnicy dla wywołań statycznych/dynamicznych. przynajmniej nie dla Linuksa / AMD64 / Java7.

Wyniki Caliper są tutaj: https://microbenchmarks.appspot.com/runs/1426eac9-36ca-48f0-980f-0106af064e8f#r:scenario.benchmarkSpec.methodName,scenario.vmSpec.options.CMSLargeCoalSurplusPercent,scenario.vmSpec.options.CMSLargeSplitSurplusPercent,scenario.vmSpec.options.CMSSmallCoalSurplusPercent,scenario.vmSpec.options.CMSSmallSplitSurplusPercent,scenario.vmSpec.options.FLSLargestBlockCoalesceProximity,scenario.vmSpec.options.G1ConcMarkStepDurationMillis

A moje własne wyniki to:

Static: 352 ms
Dynamic: 353 ms
Static: 348 ms
Dynamic: 349 ms
Static: 349 ms
Dynamic: 348 ms
Static: 349 ms
Dynamic: 344 ms

The Klasa testowa zacisku to:

public class TestPerfomanceOfStaticMethodsCaliper extends Benchmark {

    public static void main( String [] args ){

        CaliperMain.main( TestPerfomanceOfStaticMethodsCaliper.class, args );
    }

    public int timeAddDynamic( long reps ){
        int r=0;
        for( int i = 0; i < reps; i++ ) {
            r |= addDynamic( 1, i );
        }
        return r;
    }

    public int timeAddStatic( long reps ){
        int r=0;
        for( int i = 0; i < reps; i++ ) {
            r |= addStatic( 1, i );
        }
        return r;
    }

    public int addDynamic( int a, int b ){

        return a+b;
    }

    private static int addStatic( int a, int b ){

        return a+b;
    }

}

A moja klasa testowa to:

public class TestPerformanceOfStaticVsDynamicCalls {

    private static final int RUNS = 1_000_000_000;

    public static void main( String [] args ) throws Exception{

        new TestPerformanceOfStaticVsDynamicCalls().run();
    }

    private void run(){

        int r=0;
        long start, end;

        for( int loop = 0; loop<10; loop++ ){

            // Benchmark

            start = System.currentTimeMillis();
            for( int i = 0; i < RUNS; i++ ) {
                r += addStatic( 1, i );
            }
            end = System.currentTimeMillis();
            System.out.println( "Static: " + ( end - start ) + " ms" );

            start = System.currentTimeMillis();
            for( int i = 0; i < RUNS; i++ ) {
                r += addDynamic( 1, i );
            }
            end = System.currentTimeMillis();
            System.out.println( "Dynamic: " + ( end - start ) + " ms" );

            // Do something with r to keep compiler happy
            System.out.println( r );

        }

    }

    private int addDynamic( int a, int b ){

        return a+b;
    }

    private static int addStatic( int a, int b ){

        return a+b;
    }

}

Metody, które możesz zadeklarować jako statyczne, to te, które nie wymagają tworzenia instancji, takie jak

public class MyClass
{
    public static string InvertText(string text)
    {
        return text.Invert();
    }
}

Które można następnie w zamian wywołać w dowolnej innej klasie bez instancjowania tej klasy.

public class MyClassTwo
{
    public void DoSomething()
    {
        var text = "hello world";
        Console.Write(MyClass.InvertText(text));
    }
}

... Ale to pewnie już wiesz. Nie daje to żadnych realnych korzyści jako takich, poza wyjaśnieniem, że metoda nie używa żadnych zmiennych instancji.