Esistono convenzioni di ordinamento del metodo Java? [chiuso]

159

Ho una classe di grandi dimensioni (circa 40 metodi) che fa parte di un pacchetto che presenterò come corso di lavoro. Attualmente, i metodi sono piuttosto confusi in termini di utilità pubblica / privata ecc. E voglio ordinarli in modo ragionevole. Esiste un modo standard per farlo? Ad esempio, normalmente i campi sono elencati prima dei metodi, i costruttori sono elencati prima di altri metodi e ultimi getter / setter; che dire dei restanti metodi?

java methods conventions

— Fredley
fonte

Inoltre, quando lavori con un codice come questo, la maggior parte degli IDE ti consente di vedere automaticamente la definizione di qualunque cosa si trovi sotto il cursore. Questo significa che non devi fare altro che dare un'occhiata.

— Thorbjørn Ravn Andersen,

Se hai 40 metodi in una singola classe - stai sbagliando

— Ben

132

Alcune convenzioni elencano prima tutti i metodi pubblici e poi tutti quelli privati - ciò significa che è facile separare l'API dall'implementazione, anche quando non è coinvolta alcuna interfaccia, se capisci cosa intendo.

Un'altra idea è quella di raggruppare insieme i metodi correlati - questo rende più facile individuare cuciture in cui è possibile dividere la classe esistente esistente in più classi più piccole e più mirate.

— Jon Skeet
fonte

1

+1. Preferisco ordinare in base alla visibilità. Shame Eclipse non può farlo automaticamente (raggrupperà sempre tutti i costruttori insieme e tutti i metodi insieme).

— finnw

16

@finnw, presentare una segnalazione di bug. Le cose più strane sono state conosciute per essere implementate da lì.

— Thorbjørn Ravn Andersen,

3

@Ben: La mia esperienza è che qualsiasi "mai" avrà eccezioni.

— Jon Skeet,

1

@JonSkeet in alcuni casi, in cui le convenzioni di ordinazione non sono più pertinenti, ad esempio le classi di test. Non scrivere codice errato è meglio consigliare di come organizzare il codice errato.

— Ben

1

@Ben: penso che dovremo concordare di non essere d'accordo. Ho scritto un codice in cui ci sono molti membri naturalmente, senza violare alcuna separazione di preoccupazioni ecc.

— Jon Skeet,

121

Variabili di classe (statiche): prima le variabili di classe pubbliche, quindi quelle protette e quindi quelle private.
Variabili di istanza: prima pubbliche, quindi protette e quindi private.
Costruttori
Metodi: questi metodi dovrebbero essere raggruppati per funzionalità piuttosto che per ambito o accessibilità. Ad esempio, un metodo di classe privata può trovarsi tra due metodi di istanza pubblica. L'obiettivo è facilitare la lettura e la comprensione del codice.

Fonte: http://www.oracle.com/technetwork/java/codeconventions-141855.html

— Michael
fonte

4

Questo ha 15 anni e probabilmente un po 'obsoleto con l'aspetto dei moderni IDE ...

— assylias,

16

@assylias: IMO, la leggibilità è indipendente dall'IDE. Mantenere il pubblico prima del privato è di solito meglio.

— saurabheights,

40

Il collegamento più preciso a «Convenzioni del codice»: «Dichiarazioni di classe e interfaccia»

— Timofey Gorshkov
fonte

8

+1, afaik: questo è l'UNICO post che risponde effettivamente alla domanda. SÌ, esiste un ordine standard come dettato da Oracle e Sun: 1. commento pubblico, 2. classe, 3. commento interno, 4. dati statici, 5. dati di istanza, 6. ctors, 7. metodi e all'interno di ciascun gruppo di sezioni logicamente, non per accessibilità.

— John Henckel,

@VadimKirilchuk «Internet Archive» era inattivo ...

— Timofey Gorshkov

1

oracle.com/technetwork/java/codeconvtoc-136057.html

— Elder Geek

15

Non sono sicuro se esiste uno standard universalmente accettato ma le mie preferenze lo sono;

prima i costruttori
metodi statici successivi, se esiste un metodo principale, sempre prima di altri metodi statici
successivi metodi non statici, di solito in ordine di significato del metodo seguito da tutti i metodi che chiama. Ciò significa che i metodi pubblici che chiamano altri metodi di classe appaiono verso l'alto e i metodi privati che non chiamano altri metodi di solito finiscono verso il basso
metodi standard piace toString, equalse hashcodeil prossimo
Getter e setter hanno un posto speciale riservato proprio in fondo alla classe

— Qwerky
fonte

Preferisco davvero i costruttori per ultimi perché un costruttore scritto correttamente dovrebbe fare ben poco altro che assegnare i suoi argomenti alle proprietà.

— GordonM,

@GordonM Perché la pensi così? Andrei al punto di sostenere che è vero il contrario. Dovresti sempre pensare all'API più pulita per le tue classi. E spesso questo non è il modo in cui sono archiviati, quindi spesso faccio un bel po 'di elaborazione per sollevare il chiamante da questo onere

— Neuron

@GordonM Non sto parlando di effetti collaterali. Quindi nessuna modifica agli elenchi passati o simili. Passare e impostare i valori richiede che la Classe ti dica molto sulla sua implementazione, il che non dovrebbe essere il caso

— Neuron

@LonelyNeuron Non sono del tutto sicuro di quello che stai dicendo qui, ma sembra che tu stia dicendo che il costruttore dovrebbe fare un sacco di lavoro di installazione diverso dall'assegnare i suoi argomenti allo stato interno. Questo è sicuramente sbagliato, perché significa che le cose stanno accadendo per "magia". Una chiamata a new Thing()dovrebbe solo comportare un'istanza di una nuova cosa. Non dovrebbe comportare l'apertura di connessioni al database, la scrittura di file, ecc.

— Ecc

@LonelyNeuron Avere dipendenze in un costruttore non ti dice nulla sull'implementazione della classe oltre a quali siano le sue dipendenze. Questa è una buona cosa, non una cattiva.

— GordonM,

12

40 metodi in una singola classe sono un po 'troppo.

Avrebbe senso spostare alcune funzionalità in altre classi - opportunamente nominate -. Quindi è molto più facile dare un senso.

Quando ne hai meno, è molto più facile elencarli in un ordine di lettura naturale. Un paradigma frequente è elencare le cose prima o dopo che ne hai bisogno, nell'ordine in cui ne hai bisogno.

Questo di solito significa che main()va in cima o in fondo.

— Thorbjørn Ravn Andersen
fonte

1

sei così giusto - questo non è un problema di ordinazione

— kostja

4

Non hai sempre scelta, ad esempio se stai implementando un'interfaccia con molti metodi.

— Finnw,

5

Si tratta di un'attività di Android, quindi ci sono un sacco che semplicemente non possono andare altrove, onPause(), onResume()ecc, così come tutti i miei OnClickListenercampi, che, anche se sono i campi, non guardare o comportarsi come loro quindi è ragionevole elencali separatamente.

— Fredley,

@finnw, le classi astratte sono carine e utilizzabili per questo scopo.

— Thorbjørn Ravn Andersen,

11

La mia "convenzione": statica prima dell'istanza, pubblica prima del privato, costruttore prima dei metodi, ma metodo principale in fondo (se presente).

— eljenso
fonte

2

Inoltre, eclipse offre la possibilità di ordinare i membri della classe per te, se per qualche motivo li hai confusi:

Apri il tuo file di classe, vai su "Origine" nel menu principale e seleziona "Ordina membri".

preso da qui: metodi di ordinamento in Eclipse

— Stephan Richter
fonte

1

Stai usando Eclipse? In tal caso, rimarrei con l'ordinamento predefinito dei membri, perché è probabile che sia più familiare a chiunque legga il tuo codice (anche se non è il mio ordinamento preferito).

— finnw
fonte