"Più" e "meno" sono i nomi dei metodi appropriati?

Java SE 8 è dotato di un nuovo meccanismo per le date, l'introduzione LocalDate, LocalTimee LocalDateTimele classi per rappresentare istanti di tempo. Per manipolare tali istanti, un insieme di metodi sono indicati: LocalDate.plusDays(...), LocalDate.minusDays(...)e così via.

Ho sempre pensato che la buona pratica consistesse nel nominare metodi dopo che i verbi ne descrivevano lo scopo, dato che i metodi sono, in realtà, operazioni da eseguire, qualcosa che eseguirà un'azione. Solo per citare, se si considera le classi come StringBuilder, per esempio, i nomi di metodi sono append, insert, delete...

Questo è il motivo per cui per me non sembra giusto nominare un metodo plusDaysanziché sumDays, minusDaysanziché subtractDays. Sono solo io a trovarlo molto fastidioso? Cosa pensi?

L'unica ragione a cui riesco a pensare è che le date sono oggetti immutabili, quindi chiamando plusDaysnon si aggiungono giorni all'oggetto originale ma si crea uno nuovo con nuove proprietà, ma è molto sottile.

java methods naming-standards

— Luigi Cortese
fonte

Penso che tu lo stia guardando troppo tecnicamente. L'obiettivo effettivo per i nomi dei metodi è chiarire cosa fa e renderlo leggibile. Si scopre solo che nominarli con i verbi di solito raggiunge questi due obiettivi. Tuttavia, considera un metodo chiamato sqrtche accetta la radice quadrata. Denominare questo metodo takeSqrtpotrebbe sembrare sensato in base alla tua regola, ma nominarlo non renderebbe il metodo più leggibile né lo renderebbe più chiaro.

— Brandin,

La programmazione non è "inglese". Ad esempio, sqrtè solo una parola che i programmatori dovrebbero riconoscere e conoscere. A proposito, la parola inglese è "radice quadrata". Ma nominare le cose secondo ciò che è naturale in inglese non è buono. Prendi la parola "illecita", ad esempio, una parola inglese perfettamente perfetta. Tuttavia, se qualcuno chiamasse il suo metodo, dire isIllicitche penso che vorrei strapparmi gli occhi ogni volta che guardavo questa chiamata del metodo. Sembra orribile e ci deve essere un modo migliore per esprimere l'idea.

— Brandin,

sumsembra sbagliato in questo contesto. Preferisco .net's AddDays.

— Codici InCos

@LuigiCortese I nomi dei metodi sono scelti in modo da corrispondere al comune ordinamento delle parole inglesi. Math.addExact(1, 2)perché dici "aggiungi 1 e 2". tomorrow.plusDays(2)perché dici "domani più 2 giorni". Se addExactfosse stato membro di in Integerqualche modo lo sarebbe stato 1.plusExact(2).

— Tavian Barnes,

Personalmente, mi aspetto plusDaysdi restituire una nuova data x numero di giorni nel futuro, mentre addDayspotrei aspettarmi di mutare l'oggetto originale. Sono solo io, non ho molta familiarità con Java.

— Ajedi32

Risposte:

L'unica ragione a cui riesco a pensare è che le date sono oggetti immutabili, quindi chiamando plusDays non si aggiungono giorni all'oggetto originale ma si crea uno nuovo con nuove proprietà, ma è molto sottile.

Questo è esattamente il motivo. Immagina di avere una sorta di api per manipolare intervalli di date ai fini della pianificazione. Potrebbe esporre metodi che ti consentono di fare una dichiarazione come:

var workdaySchedule = initialSchedule.withoutWeekends();

Questo si legge in modo molto simile alla dichiarazione inglese: "Il programma della giornata lavorativa è il programma iniziale senza fine settimana". Non implica cambiare il programma iniziale, implica che il programma di lavoro sia una cosa diversa, nuova.

Ora invece immagina che sia stato chiamato:

var workdaySchedule = initialSchedule.removeWeekends();

Questo è confusionario. La pianificazione iniziale è stata modificata? Sembra certamente così, perché sembra che stiamo rimuovendo i fine settimana da esso. Ma allora perché lo stiamo assegnando a una nuova variabile? Sebbene questi due schemi di denominazione siano molto simili, questo è molto meno chiaramente evocativo di ciò che sta accadendo. Questo sarebbe più appropriato se removeWeekends ha fatto modificare la pianificazione iniziale, ed è tornato void- nel qual caso withoutWeekendssarebbe l'opzione di confusione.

Questa è essenzialmente una distinzione dichiarativa vs. imperativa. Stiamo dichiarando che workdayScheduleè una cosa particolare o stiamo eseguendo un elenco di istruzioni imperative (come "rimuovi") per fare quella cosa particolare? Di solito, la denominazione imperativa ha più senso quando si stanno mutando valori e dichiarativa ha più senso con valori immutabili, come dimostra l'esempio sopra.

Nel tuo caso, hai esattamente la stessa cosa. Se vedessi tomorrow.plusDays:, non immaginerei che tomorrowfosse mutato, mentre tomorrow.addDays, penserei che potrebbe essere. Questo è in qualche modo sottile ma non necessariamente negativo. Senza doverci pensare troppo, questa denominazione pone naturalmente il tuo pensiero sulla retta linea in termini di mutazione. Per rendere più chiara questa distinzione tra questi stili imperativi e dichiarativi: "add" (e "remove") sono verbi , mentre "plus" (e "without") sono preposizioni .

— Ben Aaronson
fonte

In realtà ho avuto un problema con addDaysrispetto a plusDaysieri! In .NET, la DateTimeclasse ha metodi chiamati addDays, addMonthse addYears. Ho creato il metodo per analizzare una data relativa (1 anno, 2 mesi, 3 giorni fa) e ho chiamato i metodi di cui sopra pensando che stavano modificando l' DateTimeoggetto corrente . Ogni data nel database finiva per essere l'8 giugno 2015. "È divertente", ho pensato. Fu allora che mi ricordai che addDaysnon modifica l' DateTimeoggetto, ne restituisce uno nuovo . Quindi +1 è tutto intorno per questa domanda.

— Greg Burghardt,

@GregBurghardt Come utente .NET, ho aspettative esattamente opposte. Immagino che ciò significhi solo che "più" e "aggiungi" sono intercambiabili, non mappature dirette verso +e+=

— Agent_L

@Agent_L È interessante. Convenzioni .NET a parte, "aggiungi" e "più" non sono intercambiabili in inglese.

— Ben Aaronson,

Inoltre, per date e orari, è abbastanza comune parlare di D + 1, H + 12 e così via per fare riferimento al tempo relativo a una specifica origine (anche, per il volo spaziale T-10, T-9, ecc.). Comunemente, questo viene letto come D-più-1, H-più-12, T-meno-10. Forse incentrato sugli Stati Uniti, ma è così che mi sembra.

— Kristian H,

Potresti trovare interessante questa vecchia domanda StackOverflow di Jon Skeet: qual è il nome migliore per un metodo "aggiungi" non mutante in una collezione immutabile? .

— MicSim,

In .NET la denominazione è diversa sebbene il risultato sia esattamente lo stesso. Invece di:

tomorrow = LocalDateTime.plusDays(1);

c'è:

tomorrow = DateTime.Now.AddDays(1);

Questo significa solo che le differenze tra la comprensione di "più" e "aggiungi" sono finite come una questione di opinione personale. Rallegrati, non sei solo, almeno puoi scegliere la lingua che ti piace di più:)

— Agent_L
fonte

-1

Questo è probabilmente un artefatto di Java che utilizza .Methodper tutti i metodi, sia quelli che modificano l'oggetto che quelli che non lo fanno.

Immagina un linguaggio che ha anche una object=>methodsintassi, che darebbe methoduna copia dell'oggetto su cui lavorare. Ora in una tale lingua, startDate=>plusDays(5)è chiaramente inequivocabile. Prende la data originale e crea una nuova data che è 5 giorni dopo.

Su una nota sumDaysnon correlata, non ha senso qui. LocalDateè un punto temporale , non una durata temporale . Puoi sommare un numero qualsiasi di durate (e il risultato è un'altra durata) e puoi aggiungere un punto temporale e una durata (il risultato è un altro punto temporale), ma non puoi sommare i punti temporali.

— MSalters
fonte