Convenzione di denominazione per classi di utilità in Java

115

Quando si scrivono classi di utilità in Java, quali sono alcune buone linee guida da seguire?

I pacchetti dovrebbero essere "util" o "utils"? È ClassUtil o ClassUtils? Quand'è che una classe è un "aiutante" o un "programma di utilità"? Utilità o utilità? O ne usi una miscela?

La libreria Java standard utilizza sia le utilità che le utilità:

javax.swing.Utilities
javax.print.attribute.AttributeSetUtilities
javax.swing.plaf.basic.BasicGraphicsUtils

Apache utilizza una varietà di Util e Utils, sebbene principalmente Utils:

org.apache.commons.modeler.util.DomUtil
org.apache.commons.modeler.util.IntrospectionUtils
org.apache.commons.io.FileSystemUtils
org.apache.lucene.wordnet.AnalyzerUtil
org.apache.lucene.util.ArrayUtil
org.apache.lucene.xmlparser.DOMUtils

Spring utilizza molte classi Helper e Utils:

org.springframework.web.util.UrlPathHelper
org.springframework.core.ReflectiveVisitorHelper
org.springframework.core.NestedExceptionUtils
org.springframework.util.NumberUtils

Allora, come si chiamano le classi di utilità?

java naming-conventions

— JR.
fonte

82

Come molte di queste convenzioni, ciò che è importante non è tanto la convenzione che usi, quanto che la usi in modo coerente. Ad esempio, se hai tre classi di utilità e le chiami CustomerUtil, ProductUtils e StoreUtility, le altre persone che tentano di utilizzare le tue classi si confondono costantemente e digitano CustomerUtils per errore, devono cercarlo, maledirti un paio di volte, ecc. (Ho sentito una volta una conferenza sulla coerenza in cui l'oratore ha messo una diapositiva che mostrava uno schema del suo discorso con tre punti principali, etichettati "1", "2 °" e "C".)

Mai e poi mai fare due nomi che differiscono solo per qualche sottigliezza di ortografia, come avere un CustomerUtil e un CustomerUtility. Se c'era una buona ragione per creare due classi, allora doveva esserci qualcosa di diverso in esse, e il nome dovrebbe almeno darci un'idea di quale sia questa differenza. Se uno contiene funzioni di utilità relative a nome e indirizzo e l'altro contiene funzioni di utilità correlate agli ordini, chiamarli CustomerNameAndAddressUtil e CustomerOrderUtil o qualcosa di simile. Impazzisco regolarmente quando vedo sottili differenze insignificanti nei nomi. Come ieri, stavo lavorando a un programma che aveva tre campi per i costi di trasporto, denominati "trasporto", "costo trasporto" e "prezzo". Ho dovuto studiare il codice per capire quale fosse la differenza tra loro.

— ghiandaia
fonte

9

E IV per il numero 4 :-) - Ma qual era la differenza tra nolo , nolo e trasporto ?

— KajMagnus

4

@KayMagnus Quel post risale a più di un anno fa, ma se ricordo bene, uno di questi era l'attuale costo del trasporto registrato, prima di modificare il contenuto dell'ordine e quindi potenzialmente il costo del trasporto; un altro era il costo standard del trasporto preso da una tabella; e il terzo era un costo calcolato utilizzato in alcuni casi speciali, come le spedizioni all'estero. Ad esempio, perché non potevano almeno chiamarli, ad esempio "currFreight", "stdFreight" e "calcFreight". Questo almeno avrebbe dato un indizio.

— Jay

Ok, grazie per la spiegazione :-) Un interessante esempio di codice strano credo

— KajMagnus

31

Non esiste una regola / convenzione standard nel mondo Java per questo. Tuttavia, preferisco aggiungere "s" alla fine del nome della classe come ha menzionato @colinD.

Sembra abbastanza standard per quello che fa Josh Bloch, Designer di API java Master (raccolta java e raccolta google)

Finché Helper e Util vanno, chiamerò qualcosa un Helper quando ha API che aiutano a ottenere una funzionalità specifica di un pacchetto (considerando un pacchetto come implementare un modulo); significa mentre un Util può essere chiamato in qualsiasi contesto.

Ad esempio, in un'applicazione relativa a conti bancari, tutte le API statiche di utilità specifiche per numero andranno a org.mycompany.util.Numbers

Tutte le regole aziendali specifiche per "account" che aiutano le API andrebbero a

org.mycompany.account.AccountHelper

Dopo tutto, si tratta di fornire una migliore documentazione e un codice più pulito.

— portatore dell'anello
fonte

5

Sembra ragionevole che Helper sia più specifico di Utils.

— KajMagnus

1

Sì, mi piace questo approccio, è più logico.

— Conan

3

Il collegamento è interrotto. Ne ho trovato un altro .

— Chavjoh

22

Mi piace la convenzione di aggiungere semplicemente "s" al nome del tipo quando il tipo è un'interfaccia o una classe che non controlli. Esempi di ciò nel JDK includono Collectionse Executors. È anche la convenzione utilizzata nelle raccolte di Google.

Quando hai a che fare con una classe su cui hai il controllo, direi che i metodi di utilità appartengono generalmente alla classe stessa.

— Colind
fonte

2

Anche Google Guava utilizza questo modello

— Jherico

11

Penso che "utils" dovrebbe essere il nome del pacchetto. I nomi delle classi dovrebbero specificare lo scopo della logica al suo interno. L'aggiunta del sufix -util (s) è ridondante.

— Aito
fonte

2

Questa non sarebbe la cosa giusta da fare in un approccio "pacchetto per funzionalità" .

— jpangamarca

1

@jpangamarca L'articolo che hai collegato ha un pacchetto "util" nell'esempio per "pacchetto per funzione" però. Penso che in pratica un qualche tipo di funzionalità / livello di utilità spesso non possa essere evitato.

— Kapex

1

@kapex Una svista dell'autore credo. Un tld.organization.app.utilpacchetto non dovrebbe esistere (potrebbe, ma non dovrebbe), un numero qualsiasi di tld.organization.app.feature.utilpacchetti va benissimo.

— jpangamarca

3

Sono abbastanza sicuro che le parole "helper" e "utility" siano usate in modo intercambiabile. Comunque, a giudicare dagli esempi che hai fornito, direi che se il nome della tua classe è un'abbreviazione (o contiene abbreviazioni come "DomUtil") allora chiama il tuo pacchetto "qualunque. Qualunque sia" (o Utils se c'è più di un'utilità nel tuo pacchetto ). Altrimenti, se ha un nome completo invece di un'abbreviazione, chiamalo "qualunque. Qualunque utilità".

Dipende davvero da te, ma fintanto che i programmatori sanno di cosa stai parlando, sei a posto. Se stai facendo questo professionalmente come lavoro per qualcuno, chiedi loro quali sono i loro standard di codifica prima di seguire il mio consiglio. Segui sempre gli standard del negozio, non importa cosa ti aiuterà a mantenere il tuo lavoro. :-)

— KSwift87
fonte