Perché Java ha metodi `void`?

/ Perché Java deve avere voidmetodi? Riferimento :

Qualsiasi metodo dichiarato nullo non restituisce un valore.

Per quanto posso pensare, ogni uso di voidsarebbe meglio servito restituendo un flag di stato, l'oggetto invocato, o null.

Ciò renderebbe ogni chiamata un'assegnazione assegnabile e faciliterebbe i modelli di builder e il concatenamento dei metodi. I metodi che vengono invocati solo per i loro effetti di solito restituiscono un tipo booleano o generico Successo generano un'eccezione in caso di errore.

Perché esiste una differenza tra "Questa funzione può avere successo o fallire ed è abbastanza autocosciente da poter dire la differenza" e "Non ci sono feedback sull'effetto di questa funzione". Senza void, controlleresti all'infinito i codici di successo e crederesti di scrivere un software robusto, mentre in realtà non stai facendo nulla del genere.

1. Perché C ha un voidtipo e Java è stato progettato per seguire molte delle convenzioni della famiglia del linguaggio C.
2. Esistono molte funzioni che non si desidera che restituiscano un valore. Che cosa hai intenzione di fare con "un Successtipo generico " comunque? In effetti, i valori di ritorno per indicare il successo sono ancora meno importanti in Java che in C, perché Java ha delle eccezioni per indicare l'errore e C no.

Il motivo originale per cui la lingua ha un voidtipo è perché, come in C, i creatori della lingua non volevano complicare inutilmente la sintassi della lingua con procedure e funzioni come ha fatto Pascal.

Questa era la ragione originale.

I tuoi suggerimenti:

restituendo un flag di stato

Questo è un no-no. Non utilizziamo flag di stato. Se qualcosa va storto, lo segnaliamo tramite eccezioni.

l'oggetto che viene invocato

Lo stile fluido delle invocazioni è uno sviluppo recente. Molti dei programmatori che oggi usano molto volentieri fluentemente e rotolano gli occhi se mai dovessero usare un'interfaccia che non la supporta non sono nemmeno nati al momento della creazione di Java.

restituendo null

Ciò ti costringerebbe a dichiarare un metodo come restituire qualcosa, quando in realtà non restituisce nulla, quindi sarebbe molto confuso per qualcuno che sta guardando un'interfaccia cercando di capire cosa fa. Le persone inevitabilmente inventerebbero una classe altrimenti inutile che sta per "nessun valore di ritorno" in modo che tutte le funzioni che non hanno nulla da restituire possano restituire un riferimento nullo a tale classe. Sarebbe goffo. Fortunatamente, c'è una soluzione a questo, si chiama void. E questa è la risposta alla tua domanda.

Alcuni metodi, come ad esempio System.out.println, non restituiscono nulla di utile, ma vengono chiamati puramente per questo effetto collaterale. voidè un indicatore utile per il compilatore e per il lettore di codice che non viene restituito alcun valore utile.

Restituire nullinvece di voidsignifica che avresti solo NullPointerExceptionil momento in cui usi questo valore per qualsiasi cosa. Quindi scambia un errore di compilazione con un errore di runtime che è molto peggio. Inoltre, dovresti definire il tipo di ritorno come Object, che sarebbe fuorviante e confuso. (E il concatenamento non funzionerebbe ancora.)

I codici di stato vengono generalmente utilizzati per indicare condizioni di errore, ma Java ha delle eccezioni a tale scopo.

Il ritorno thisnon è possibile da metodi statici.

Restituire un Successoggetto generico non avrebbe scopi utili.

Uno dei motivi è che può essere fuorviante per tornare sempre qualcosa di diverso, per esempio, null. Esempio:

Cosa dovrebbe Arrays.sort(a)tornare?

Se si sostiene che adovrebbe essere restituito in modo che la chiamata possa essere concatenata (che sembra essere la risposta a giudicare dalla propria domanda), non è più chiaro se il valore restituito sia una copia dell'oggetto originale o dell'oggetto originale stesso . Entrambi sono possibili. E sì, potresti metterlo nella documentazione, ma è sufficientemente ambiguo che non dovresti creare l'ambiguità in primo luogo.

D'altra parte, se si sostiene che nulldovrebbe essere restituito, ciò solleva la questione di quali informazioni il valore restituito fornisce probabilmente al chiamante e perché il programmatore dovrebbe essere costretto a scrivere return nullquando non trasmette informazioni.

E se restituisci qualcos'altro totalmente assurdo (come la lunghezza di a), allora rendere l'utilizzo del valore restituito davvero confuso - pensa solo a quanto più confuso è dire int len = Arrays.sort(a)invece di int len = A.length!

Restituire un valore booleansempre uguale a quello trueche suggerisci non è solo inutile (il valore restituito non contiene informazioni), ma in realtà sarebbe fuorviante. Il più delle volte, è meglio tipi restituiti uso che effettuano solo quante più informazioni è in realtà disponibile - è per questo che in Java si ha booleanper true/ falseinvece di restituire un intcon 4 miliardi di valori possibili. Allo stesso modo, restituendo un booleancon due possibili valori in cui esiste un solo valore possibile ("successo generico"), sarebbe fuorviante.

Aggiungerebbe anche sovraccarico di prestazioni non necessarie.

Se un metodo viene utilizzato solo per il suo effetto collaterale, non c'è nulla da restituire e il tipo restituito voidriflette esattamente questo. Potenziali errori rari possono essere segnalati tramite eccezioni.

Una cosa che potrebbe essere migliorata sarebbe quella di creare voidun tipo reale, come quello di Scala Unit. Ciò risolverebbe alcuni problemi come la gestione dei farmaci generici.

Java è un linguaggio relativamente vecchio. E nel 1995 (quando è stato creato) e poco dopo i programmatori erano molto preoccupati per la quantità di tempo in cui un processo ha preso il controllo del processore e il consumo di memoria. Il ritorno del vuoto eliminerebbe alcuni cicli di clock e un po 'di consumo di memoria da una chiamata di funzione perché non dovresti mettere il valore di ritorno nello stack e non dovresti successivamente rimuoverlo.

Un codice efficiente non ti restituisce qualcosa che non utilizzeresti mai, e quindi rendere nulla in qualcosa che ha un valore di ritorno insignificante è una pratica molto migliore in cui restituire un valore di successo.

Ho letto argomenti che suggeriscono che la seconda opzione (ritorno this) dovrebbe essere l'approccio anziché void. Questa è una buona idea, ma l'approccio in stile builder non era popolare al momento della creazione di Java. Se fosse così popolare in quel momento come lo è ora, potrebbe essere stato l'approccio adottato. Tornare nullè una cattiva idea IMO. Vorrei che nullnon fosse nemmeno nella lingua.

Il problema ora è che se un metodo restituisce un'istanza del proprio tipo, non è chiaro se si tratti di un nuovo oggetto o dello stesso. Spesso non importa (o non dovrebbe) ma altre volte importa. Suppongo che la lingua potrebbe essere cambiata per tornare implicitamente thisa metodi nulli. L'unico problema che mi viene in mente al momento è che se il metodo fosse successivamente modificato per restituire un nuovo oggetto dello stesso tipo, non ci sarebbero stati avvisi di compilazione, ma forse non è un grosso problema. L'attuale sistema di tipi non si preoccupa di questi tipi di modifiche ora. Il modo in cui questo interagisce con l'ereditarietà / le interfacce richiederebbe qualche considerazione, ma consentirebbe alle vecchie API senza uno stile builder di essere chiamate facilmente come se lo fossero.

Un altro aspetto:

Java è un linguaggio statico con funzionalità piuttosto rigide. Ciò significa che molte cose che sarebbero abbastanza aperte o dinamiche in altre lingue (c / f Ruby, Lisp ecc.) Sono rigorosamente determinate.

Questa è una decisione di progettazione generale. È difficile rispondere al "perché" (beh, perché i progettisti del linguaggio hanno pensato che sarebbe stato bello!). Il "what for" è abbastanza chiaro: consente al compilatore di rilevare molti errori, che è generalmente una buona funzionalità per qualsiasi lingua. In secondo luogo, rende relativamente facile ragionare sulla lingua. Ad esempio, è relativamente facile creare la correttezza formale che prova (sottoinsiemi) del linguaggio Java; come confronto, ciò sarebbe praticamente impossibile in un linguaggio dinamico come Ruby et al.

Questo pensiero permea la lingua, ad esempio, la dichiarazione forzata di possibili eccezioni che un metodo può generare, il tipo separato di interfacevs. classper evitare l'eredità multipla ambigua e così via. Per quello che è (un linguaggio del mondo reale OOP statico imperativo con forte attenzione alla gestione degli errori in fase di compilazione) queste cose sono in realtà piuttosto eleganti e potenti. Si avvicinano alle lingue teoriche (scientifiche) che sono state create apposta per esplorare alcuni di questi problemi rispetto a qualsiasi altra lingua del mondo reale prima (a quel tempo, attenzione).

Così. Avere un voidtipo rigoroso è un messaggio chiaro: questo metodo non restituisce nulla, punto. È quello che è. Sostituirlo con l'applicazione per restituire sempre qualcosa porterebbe a comportamenti molto più dinamici (come in Ruby dove ogni def ha un valore di ritorno esplicito o implicito, sempre), che sarebbe male per la provabilità e il ragionamento; o per gonfiare enormemente usando qualche altro meccanismo qui.

(E NB, Ruby (per esempio) gestisce in modo diverso, e la sua soluzione è ancora esattamente come accettabile come Java, perché ha una filosofia completamente diversa. Per esempio si getta dimostrabilità e ragionevolezza completamente fuori dalla finestra, mentre mettendo un grande fuoco su espressività estremamente elevata della lingua.)