Qual è il modo corretto di scrivere un setter? [chiuso]

Non ci sono differenze significative. Entrambi producono lo stesso risultato.

Personalmente preferisco la versione di Eclipse, perché trovo:

• È più elegante che il nome nell'elenco dei parametri sia lo stesso del campo utilizzato internamente nell'oggetto.
• Il nome del parametro unitCost sembra e funziona meglio nel completamento del codice rispetto a inUnitCost o simile (poiché è probabile che tu usi il nome unitCost nel codice chiamante).
• È bello essere espliciti sul fatto che stai impostando un campo con this . Il mio riconoscimento del modello di codice qui immediatamente dice "ah ... questa linea sta impostando un campo nell'oggetto corrente".

Ma alla fine è solo una scelta di stile.

Non c'è alcuna differenza significativa tra i due.

La differenza (a parte lo spazio bianco) è quella che usa esplicitamente this per impostare il nuovo valore. Per quanto ne so, non c'è alcun vantaggio o svantaggio nel farlo.

È solo una scelta di stile. Alcuni programmatori si infastidiscono di dover trovare nomi stupidi come inUnitCost o newUnitCost per i parametri di funzione. Alcuni si infastidiscono notando che il simbolo unitCost del parametro function sovrascrive il simbolo unitCost per il membro dell'oggetto. Dovresti mantenere il consenso che hai raggiunto con i tuoi colleghi.

È probabile che il primo esempio venga visualizzato in alcune cerchie come una convenzione scadente in quanto rende il valore di input come se fosse in Notazione ungherese.

Molti strumenti di completamento e formattazione del codice ti incoraggeranno a utilizzare this per essere espliciti nell'uso delle variabili. Tendo ad essere d'accordo con questo, in quanto rende molto chiaro a colpo d'occhio se la variabile è locale o appartiene alla classe. Naturalmente, se stai mantenendo tutti i tuoi metodi belli e brevi nell'ordine di poche righe, e anche gli elenchi dei parametri del metodo sono piuttosto brevi, allora potrebbe non essere necessariamente un problema per te. Personalmente preferisco ancora vedere this liberamente disseminato nel codice, poiché questo fa sì che le variabili risaltino distintamente a causa dell'evidenziazione della sintassi che i più moderni IDE ti forniscono, e meno devo effettivamente guardare nel codice troppo in profondità, meno mi distraggo saltando il codice mentre provo a risolvere problemi logici complessi nella mia testa.

Detto ciò, il compilatore non si preoccuperà del fatto che tu abbia scritto i tuoi setter. D'altro canto, i tuoi colleghi potrebbero avere opinioni divergenti, quindi sta a te decidere quale approccio vorrai inscrivere in uno standard di codifica.

Come strumento di generazione automatica del codice, il generatore Eclipse non è necessariamente legato alle stesse regole che governano ciò che vale lo sforzo per i programmatori umani. Non dimenticarlo.

I due sono completamente equivalenti in questo caso, tuttavia.

Il codice idiomatico più moderno sarebbe:

public void setUnitCost(final double unitCost)
{
     this.unitCost = unitCost;
}

1. contrassegnare l'argomento final è importante; l'utilizzo di JSR305 @ Nonnullable / @ Nullable quando si lavora con riferimenti a oggetti è ancora più utile per documentare autonomamente le intenzioni del codice.
2. this. è auto-documentante che stai impostando l'istanza corrente e non alcune variabili in una super classe, che dovrebbe usare idiomaticamente super.

Non c'è differenza tra loro. finché soddisfa il compito in modo efficiente va bene. Scrivo i miei setter (a volte) in questo modo

public void setFoo(String fooName){
  this.fooName = fooName;
}

Il motivo per cui l'ho usato è che mi manca l'idea di un'appropriata denominazione delle variabili. ma ciononostante puoi scrivere un setter che ti soddisfa.

Ma preferisco il primo setter, dal momento che potrebbero verificarsi degli errori sul secondo

Questo potrebbe spingere alcune persone nel modo sbagliato, ma direi non scrivere (o generare) codice che ottiene semplicemente o imposta una variabile, in quanto porta a ingombri e più righe di codice da leggere / scansionare per capire cosa fa la tua classe. Questa confusione può distogliere l'attenzione dal codice che in realtà ha dettagli specifici sull'implementazione, oltre a ottenere o impostare semplicemente una variabile.

La libreria Lombok fornisce @Getter & @Inserire setti per alleggerirti dal dover scrivere (e altri da leggere) metodi "muti" getter e setter. Al momento della compilazione, Lombok genererà questi metodi per te e la loro integrazione IDE non ti farà notare la differenza durante lo sviluppo.

(C'è anche un'opzione de-lombok per generare codice sorgente con getter e setter appropriati, senza alcuna dipendenza da Lombok, ma non lo consiglierei a meno che non si debbano soddisfare alcuni requisiti davvero bizzarri.)

Non ha molta importanza. Nessuno guarderà mai il codice sorgente per il tuo setter se è banale come quello, quindi a nessuno importa quale sia il metodo che stai usando.

Direi che si dovrebbe sempre preferire

public void setUnitCost (double unitCost){
     this.unitCost = unitCost;
}

in codice Java. Sembra essere la convenzione seguita dalla maggior parte degli sviluppatori Java. Almeno la maggior parte del codice Java che ho visto negli ultimi 15 anni è scritta in questo modo. Questo è il codice di varie codebase, aziende, progetti, frammenti di codice ed esempi. Non seguire le convenzioni non è di per sé una cosa negativa, ma di solito è una causa di frizione (in questo caso offenderete leggermente il riconoscimento del modello di un cervello Java addestrato), e dovrebbe essere giustificato con un guadagno significativo, che non riesco a vedere qui.

Un altro punto sarebbe che il prefisso di variabili / parametri con contesto semantico (notazione ungherese, in / out per i parametri in / out, ecc.) è ampiamente scoraggiato in tutta la comunità di programmazione, al giorno d'oggi. Questi prefissi hanno la tendenza a mentire dopo alcuni refactoring. I setter sono abbastanza semplici, che è sicuro dire che il parametro sarà sempre un parametro (altrimenti non sarebbe più un setter, vero?). Dovresti avere la stessa convenzione per i nomi nella base di codice, però, compresi i setter.

Qualcosa che non è stato menzionato nelle altre risposte, l'idioma comune

this.unitCost = unitCost;

sarà un bug difficile da individuare se si dimentica il this solo una volta in un code base.

Dichiarare il parametro come final potrebbe sembrare una salvaguardia, ma in pratica la maggior parte dei programmatori lascia che l'IDE lo faccia automaticamente e ovviamente non lo farà una volta che avrai la riga unitCost = unitCost; nel tuo codice.

Quindi vedo una buona ragione per usare il primo idioma, cioè rendere diverso il nome del parametro e del campo:

unitCost = pUnitCost; //p for parameter