Uso intenso di metodi statici in un'applicazione Web Java EE?

Direi che solo leggendo la tua analisi, stai dicendo che ci sono molti metodi statici e singleton. I metodi statici non dovrebbero essere un problema da soli, ma se vengono utilizzati per il proxy delle chiamate agli oggetti Singleton, lavorerò per renderli solidi o sostituirli con un modello di oggetti più sano.

I metodi statici sono utili per scopi puramente funzionali, e troverai sia i linguaggi di programmazione Scala che Clojure per usarli molto, soprattutto perché non devono preoccuparsi dello stato mutabile.

Lettura dal post di questo blog sui metodi di Java Static / Class (ho evidenziato un bit pertinente):

Static methods use no instance variables of any object of the class they are defined in. If you define a method to be static, you will be given a rude message by the compiler if you try to access any instance variables. You can access static variables, but except for constants, this is unusual. Static methods typically take all they data from parameters and compute something from those parameters, with no reference to variables. This is typical of methods which do some kind of generic calculation. A good example of this are the many utility methods in the predefined Math class. (See Math and java.util.Random).

Non è certamente idiomatico in Java, C # o nella maggior parte dei linguaggi OO avere molti metodi statici che fanno ipotesi sullo stato dell'universo (tipicamente indicato dall'uso di variabili statiche). Ho sperimentato il dolore di districare almeno due applicazioni su larga scala e un progetto di test di integrazione che ha introdotto variabili statiche ovunque, incluso uno che consentiva l'istanza di un solo utente in un dato momento, poiché il metodo statico User.getUser () era l'unico modo per ottenere un'istanza attiva della classe utente. È stato molto doloroso.

Tuttavia, era un codice cattivo. Ho visto codice cattivo proprio come questo in C #, in Perl e in C ++. È una stampella a cui si rivolge una certa categoria di programmatori procedurali perché sembra piuttosto familiare. Lo stato globale è facile da capire, finché non è stato prodotto un numero sufficiente che non lo è.

Ci sono alcune cose per le quali lo stato globale ha senso, ma in un'applicazione idiomatica Java, queste dovrebbero essere limitate a non molto più di un framework di logging (in modo che tu possa chiamare qualcosa come LogManager.getLogger ("somename") , la mappa dei collegamenti delle dipendenze globali che potrebbe essere richiesta da un framework di iniezione delle dipendenze e forse qualcosa che è piuttosto costoso da compilare, come una factory di sessione del mappatore di oggetti relazionale.

Se stai utilizzando Spring in modo sensibile, la ricerca delle dipendenze è in genere limitata a una parte ristretta dell'applicazione. Ho visto Spring utilizzato essenzialmente per implementare il pattern Service Locator, che essenzialmente ha ogni costruttore di classe chiedere le sue dipendenze chiamando a Spring, ma questo è solo chiedendo dolore in seguito e di solito frena la testabilità, dal momento che i test unitari non dovrebbero aver bisogno fare affidamento sulla struttura di iniezione delle dipendenze. Invece, il luogo degli usi di Spring dovrebbe essere piccolo: di solito ho la fabbrica di controller in un progetto MVC per costruire le dipendenze necessarie. Per i servizi, di solito c'è anche un posto ragionevole che puoi collegare in modo relativamente stretto.

Considerando che J2EE era una sorta di architettura-astronauta di purezza degli oggetti, sarei quasi più sorpreso di vedere molto statico (globale) in un'app J2EE. Tuttavia, sapendo che molti ingegneri junior che non sanno come fare un accoppiamento libero sensibilmente e gli ingegneri senior trincerati in modi procedurali per risolvere i problemi sono spesso lanciati in un progetto su larga scala, non è in realtà così sorprendente vedere gli spaghetti e le polpette si avvicinano a un dominio problematico poco compreso quando è stata inserita la giusta combinazione di persone sbagliate.

Le statistiche dovrebbero essere usate quando non si vuole avere un comportamento variabile per oggetti diversi.

Le statistiche dovrebbero essere utilizzate quando i dati non dipendono dall'istanza e per tutte le istanze esistenti di membri statici si desidera applicare lo stesso stato.

Le statistiche non dovrebbero essere usate affatto Se non sono realmente necessarie in quanto creano dipendenze e riferimenti ad altre classi e caricatore di classi in JVM e rimangono in memoria per lungo tempo. Quindi non sono considerati per la garbage collection una volta che hanno finito il lavoro corrente, ma sono de-referenziati con le loro classi di caricamento man mano che mantengono un riferimento alle classi statiche. Leggi di più- link