Nota che IDEA ha questa ispezione anche per Java, si chiama Metodo può essere "statico" ,
Questa ispezione riporta tutti i metodi che possono essere tranquillamente resi statici. Un metodo può essere statico se non fa riferimento a nessuno dei metodi non statici della sua classe e ai campi non statici e non viene sostituito in una sottoclasse ...
Il fatto è che per il codice Java, questa ispezione è disattivata per impostazione predefinita (il programmatore può accenderlo a propria discrezione). La ragione di ciò è molto probabile che la validità / utilità di tale ispezione potrebbe essere messa in discussione, sulla base di un paio di fonti abbastanza autorevoli.
Per cominciare, il tutorial Java ufficiale è piuttosto restrittivo su quando i metodi dovrebbero essere statici:
Un uso comune dei metodi statici è l'accesso ai campi statici.
Dato sopra, si potrebbe sostenere che l'attivazione dell'ispezione menzionata per impostazione predefinita non è conforme all'uso raccomandato del modificatore statico in Java.
Inoltre, ci sono un paio di altre fonti che arrivano fino a suggerire un approccio giudizioso sull'uso di idee alla base di questa ispezione o addirittura a scoraggiarla.
Vedi ad esempio l'articolo di Java World - Mr. Happy Object insegna metodi statici :
Qualsiasi metodo indipendente dallo stato dell'istanza è un candidato per essere dichiarato statico.
Nota che dico "candidato per essere dichiarato statico". Anche nell'esempio precedente nulla ti costringe a dichiarare instances()come statico. Dichiararlo come statico semplifica la chiamata poiché non è necessaria un'istanza per chiamare il metodo. A volte avrai metodi che non sembrano basarsi sullo stato dell'istanza. Potresti non voler rendere statici questi metodi. In effetti, probabilmente vorrai dichiararli statici solo se devi accedervi senza un'istanza.
Inoltre, anche se puoi dichiarare un metodo come statico, potresti non volerlo a causa dei problemi di eredità che interferisce nella tua progettazione. Dai un'occhiata a "Design orientato agli oggetti efficace" per vedere alcuni dei problemi che dovrai affrontare ...
Un articolo sul blog di test di Google arriva persino a sostenere che i metodi statici sono Death to Testability :
Facciamo un esercizio mentale. Supponiamo che la tua applicazione non abbia altro che metodi statici. (Sì, è possibile scrivere un codice del genere, si chiama programmazione procedurale.) Ora immagina il grafico di chiamata di quell'applicazione. Se si tenta di eseguire un metodo leaf, non si avranno problemi a configurarne lo stato e ad affermare tutti i casi angolari. Il motivo è che un metodo foglia non effettua ulteriori chiamate. Man mano che ti allontani dalle foglie e ti avvicini al main()metodo della radice , sarà sempre più difficile impostare lo stato nel test e sarà più difficile affermare le cose. Molte cose diventeranno impossibili da affermare. I tuoi test diventeranno progressivamente più grandi. Una volta raggiunto ilmain()metodo non hai più un test di unità (poiché la tua unità è l'intera applicazione) ora hai un test di scenario. Immagina che l'applicazione che stai cercando di testare sia un elaboratore di testi. Non c'è molto che puoi affermare dal metodo principale ...
A volte un metodo statico è una fabbrica per altri oggetti. Ciò esalta ulteriormente il problema del test. Nei test ci affidiamo al fatto che possiamo collegare oggetti in modo diverso sostituendo importanti dipendenze con beffe. Una volta newchiamato un operatore, non possiamo sovrascrivere il metodo con una sottoclasse. Un chiamante di una tale fabbrica statica è permanentemente legato alle classi concrete prodotte dal metodo della fabbrica statica. In altre parole, il danno del metodo statico è molto al di là del metodo statico stesso. Inserire il cablaggio del grafico a oggetti e il codice di costruzione nel metodo statico è un problema, dal momento che il cablaggio del grafico a oggetti è il modo in cui isoliamo le cose per i test ...
Vedete, dato sopra sembra naturale che l'ispezione menzionata sia disattivata di default per Java.
Gli sviluppatori IDE avrebbero davvero difficoltà a spiegare perché pensano che è così importante come impostarlo per impostazione predefinita, contro le raccomandazioni ampiamente riconosciuti e best practice.
Per Groovy, le cose sono abbastanza diverse. Nessuno degli argomenti sopra elencati si applica, in particolare quello sulla testabilità, come spiegato ad esempio in Mocking Static Methods nell'articolo di Groovy su Javalobby:
Se la classe Groovy che stai testando rende le chiamate un metodo statico su un'altra classe Groovy, allora potresti utilizzare ExpandoMetaClass che ti consente di aggiungere dinamicamente metodi, costruttori, proprietà e metodi statici ...
Questa differenza è probabilmente il motivo per cui l'impostazione predefinita per l'ispezione menzionata è opposta in Groovy. Mentre in Java l'impostazione predefinita "on" sarebbe fonte di confusione per gli utenti, in Groovy, un'impostazione opposta potrebbe confondere gli utenti IDE.
"Ehi, il metodo non usa i campi di istanza, perché non mi hai avvertito?" A questa domanda sarebbe facile rispondere per Java (come spiegato sopra), ma per Groovy non esiste una spiegazione convincente.