Pamiętaj, że IDEA ma również tę inspekcję w Javie, nazywa się to Metoda może być „statyczna” ,
Ta inspekcja zgłasza wszelkie metody, które można bezpiecznie unieruchomić. Metoda może być statyczna, jeśli nie odwołuje się do żadnych metod niestatycznych i pól niestatycznych swojej klasy i nie jest zastępowana w podklasie ...
Rzecz w tym, że w przypadku kodu Java ta kontrola jest domyślnie wyłączona (programiści mogą ją włączyć według własnego uznania). Powodem tego jest najprawdopodobniej, że ważność / przydatność takiej inspekcji mogłaby zostać zakwestionowana na podstawie kilku dość wiarygodnych źródeł.
Na początek oficjalny samouczek Java jest raczej ograniczony, kiedy metody powinny być statyczne:
Częstym zastosowaniem metod statycznych jest dostęp do pól statycznych.
Biorąc pod uwagę powyższe, można argumentować, że włączenie domyślnie wspomnianej kontroli nie jest zgodne z zalecanym użyciem modyfikatora statycznego w Javie.
Poza tym istnieje kilka innych źródeł, które sięgają tak daleko, że sugerują rozsądne podejście do korzystania z pomysłów leżących u podstaw tej kontroli, a nawet zniechęcają ją.
Zobacz na przykład artykuł Java World - Mr. Happy Object uczy metod statycznych :
Każda metoda, która jest niezależna od stanu instancji, może zostać zadeklarowana jako statyczna.
Pamiętaj, że mówię „kandydat do bycia zadeklarowanym jako statyczny”. Nawet w poprzednim przykładzie nic nie zmusza cię do zadeklarowania instances()jako statycznego. Zadeklarowanie go jako statycznego sprawia, że wygodniej jest wywoływać, ponieważ nie potrzebujesz instancji, aby wywołać metodę Czasami będziesz mieć metody, które wydają się nie polegać na stanie instancji. Być może nie chcesz, aby te metody były statyczne. W rzeczywistości prawdopodobnie będziesz chciał zadeklarować je jako statyczne, jeśli potrzebujesz do nich dostępu bez instancji.
Co więcej, nawet jeśli możesz zadeklarować taką metodę jako statyczną, możesz tego nie chcieć z powodu problemów z dziedziczeniem, które wtrąca się w twój projekt. Spójrz na „Efektywne projektowanie obiektowe”, aby zobaczyć niektóre z problemów, z którymi się spotkasz ...
Artykuł na blogu testowym Google mówi nawet, że metody statyczne to śmierć na testowalność :
Zróbmy ćwiczenie mentalne. Załóżmy, że twoja aplikacja ma tylko statyczne metody. (Tak, taki kod można napisać, nazywa się to programowaniem proceduralnym.) Teraz wyobraź sobie graf wywołania tej aplikacji. Jeśli spróbujesz wykonać metodę liścia, nie będziesz mieć problemu z ustawieniem jej stanu i potwierdzeniem wszystkich przypadków narożnych. Powodem jest to, że metoda liścia nie wykonuje dalszych wywołań. W miarę oddalania się od liści i zbliżania się do main()metody rootowania coraz trudniej będzie ustawić stan w teście i trudniej będzie stwierdzić. Wiele rzeczy stanie się niemożliwych do stwierdzenia. Twoje testy będą się stopniowo powiększać. Po dotarciu domain()metoda, w której nie masz już testu jednostkowego (ponieważ twoją jednostką jest cała aplikacja) masz teraz test scenariuszowy. Wyobraź sobie, że aplikacja, którą próbujesz przetestować, to edytor tekstu. Nie można wiele stwierdzić na podstawie głównej metody ...
Czasami metody statyczne są fabryką dla innych obiektów. To dodatkowo nasila problem z testowaniem. W testach polegamy na tym, że możemy różnie łączyć obiekty, zastępując ważne zależności próbnymi. Po newwywołaniu operatora nie możemy zastąpić metody podklasą. Osoba wywołująca taką statyczną fabrykę jest trwale związana z konkretnymi klasami, które wytworzyła metoda statycznej fabryki. Innymi słowy, uszkodzenie metody statycznej znacznie wykracza poza samą metodę statyczną. Włączenie okablowania wykresów obiektowych i kodu konstrukcyjnego do metody statycznej jest wyjątkowo złe, ponieważ okablowanie wykresów obiektowych to sposób, w jaki izolujemy rzeczy do testowania ...
Widzisz, biorąc pod uwagę powyższe, wydaje się naturalne, że wspomniana inspekcja jest domyślnie wyłączona w Javie.
Deweloperzy IDE miałoby naprawdę trudno wyjaśnić, dlaczego uważają, że tak ważne jest, aby ustawić go na domyślnie przeciwko powszechnie uznanych zaleceń i najlepszych praktyk.
W przypadku Groovy sprawy wyglądają zupełnie inaczej. Żaden z wyżej wymienionych argumentów nie ma zastosowania, szczególnie ten dotyczący testowalności, jak wyjaśniono np. W Mocking Static Methods w artykule Groovy w Javalobby:
Jeśli testowana klasa Groovy wywołuje metodę statyczną w innej klasie Groovy, możesz użyć ExpandoMetaClass, która umożliwia dynamiczne dodawanie metod, konstruktorów, właściwości i metod statycznych ...
Ta różnica jest prawdopodobna, dlaczego domyślne ustawienie wspomnianej kontroli jest odwrotne w Groovy. Podczas gdy w Javie domyślne „włączone” byłoby źródłem zamieszania wśród użytkowników, w Groovy przeciwne ustawienie mogłoby pomylić użytkowników IDE.
„Hej, metoda nie wykorzystuje pól instancji, dlaczego mnie przed tym nie ostrzegłeś?” Odpowiedź na to pytanie byłaby łatwa w przypadku Javy (jak wyjaśniono powyżej), ale w przypadku Groovy nie ma żadnego przekonującego wyjaśnienia.