È l'uso delle classi *** Helper o *** Util che contengono solo metodi statici un AntiPattern

Bene, Java non ha funzioni libere, quindi sei costretto a metterle come funzioni statiche in qualche classe pro-forma. Un work-around necessario non è mai un anti-pattern, anche se potrebbe mancare di eleganza.

Successivamente, non c'è nulla di sbagliato nelle funzioni gratuite. In realtà, l'uso di funzioni libere riduce l'accoppiamento, in quanto hanno accesso all'interfaccia pubblica invece di tutti i dettagli cruenti.

Ovviamente, l'uso di funzioni libere / statiche non allevia in alcun modo i pericoli dello stato mutabile, specialmente globale,.

Le utilità statiche o le funzioni di supporto non sono un modello anti se rispettano alcune linee guida:

1. Devono essere privi di effetti collaterali

2. Vengono utilizzati per comportamenti specifici dell'applicazione che non appartengono alla classe o alle classi su cui operano queste funzioni

3. Non richiedono alcuno stato condiviso

Casi di utilizzo comune:

• Formattare le date in modo specifico per l'applicazione
• Funzioni che accettano un tipo come input e restituiscono un tipo diverso.

Ad esempio, in un'applicazione ho lavorato su utenti che tenevano le voci del diario per le loro attività. Possono specificare una data di follow-up e scaricare un promemoria dell'evento. Abbiamo creato una classe di utilità statica per prendere una voce di diario e restituire il testo non elaborato per un file .ics.

Non ha richiesto alcun stato condiviso. Non ha mutato nessuno stato e la creazione di un evento iCal era certamente specifica per l'applicazione e non apparteneva alla classe della voce del diario.

Se le funzioni statiche o le classi di utilità hanno effetti collaterali o richiedono uno stato condiviso, ti consigliamo di rivalutare questo codice, poiché introduce un accoppiamento che può essere difficile prendere in giro per il test dell'unità.

Dipenderà dal tuo approccio. Molte applicazioni sono scritte con una mentalità più funzionale, al contrario di quella classica (inclusa la maggior parte della suite di siti su cui ti trovi).

Con questa mentalità, ci saranno molti metodi di utilità sulle classi worker che possono essere messi insieme come metodi statici. Vengono alimentati / utilizzati più vicino a oggetti semplici che contengono solo dati e vengono passati in giro.

È un approccio valido e può funzionare molto bene, soprattutto su scala.

Personalmente ritengo che l'unica parte importante di queste classi di helper sia che siano rese private. Oltre a questo - sono strettamente una buona idea (applicata con parsimonia).

Il modo in cui penso a questo - è se nell'implementazione di una classe (o funzione) - qualcosa di simile è utile, e rende l'implementazione più chiara, come potrebbe essere male? E spesso è fondamentale definire tali classi di helper private per consentire l'integrazione e l'uso di altri algoritmi che dipendono dal fatto che i dati si trovino in una particolare forma.

Se etichettarlo, l'helper è una piccola questione di gusto personale, ma connota che aiuta nell'implementazione e il suo non interesse / uso per un pubblico più ampio. Se questo è ciò che ha senso, provaci!

La prevalenza delle classi helper static in base a un equivoco. Solo perché chiamiamo le classi con solo static metodi "classi di utilità" non significa che non è consentito scrivere comportamenti comuni nei POJO.

static sono anti-pattern per tre motivi:

1. L'accesso statico a questi metodi helper nasconde le dipendenze . Se queste "classi di utilità" fossero POJO, si potrebbero iniettarle int a una classe dipendente come parametri costruttore che renderebbe la dipendenza ovvia per qualsiasi utente di una classe dipendente.

2. L'accesso statico a questi metodi helper causa accoppiamento stretto . Ciò significa che il codice che usa i metodi helper è difficile da riutilizzare e (come effetto collaterale) da testare.

3. Specialmente se mantengono stato queste sono semplicemente variabili globali . E si spera che nessuno sostenga che le variabili globali siano buone ...

Le classi di helper statico fanno parte del codice STUPID anti pattern.

Global state is unrelated to the question, – max630

L'OP ha scritto:

But mostly it is indeed context dependent and statefull.

Costrutti statici statici sono stati globali.

any kind of code can use it. – max630

Sì, di causa. E quasi tutte le applicazioni hanno bisogno di una sorta di stato globale .

Ma stato globale ! = variabile globale .

Puoi creare stato globale con le tecniche OO tramite dependency injection ma non puoi evitare lo stato globale con strutture statiche statiche che sono variabili globali a il fondo.