2010-08-11 8 views
8

Non vedo alcuna differenza tra i seguenti due metodi di creazione di un setter, ma mi chiedevo se sono solo ingenuo. È più desiderabile dell'altra?Uso di "this" nei setter

public void fooSetter(String bar) 
{ 
    _bar = bar; 
} 


public void fooSetter(String bar) 
{ 
    this._bar = bar; 
} 
+8

i tuoi campi non dovrebbero iniziare con underscore. Anche se questo è discutibile, potrebbe causare problemi con i framework che manipolano il pojo. – Bozho

risposta

16

non c'è differenza semantica in questo caso perché non c'è ambiguità. Se, d'altra parte, il vostro campo di istanza è stato chiamato anche bar poi this sarebbe necessario per evitare ambiguità:

public void fooSetter(String bar) 
{ 
    this.bar = bar; 
} 
+4

Vale la pena dire che il carattere di sottolineatura in '_bar' non è convenzionale per le variabili dei membri privati ​​in Java - in genere solo' bar'. –

+0

Corretto, _bar non è convenzionale, ma sembra più compatto di m_bar e il significato sembra ancora chiaro. –

+0

@Noel M: È vero. Naturalmente, l'API core sembra amare anche i parametri a lettera singola per i metodi setter. =/ –

7

Non è necessario "questo" poiché non vi è alcuna ambiguità. ("bar" e "_bar" sono diversi, ora se il tuo campo era chiamato "bar", ne avresti bisogno)

+1

'questo' non è solo per non chiarire le cose - solo per essere esplicito per il riferimento a variabili di quell'istanza. Tendo ad usarlo anche se non c'è bisogno di disambiguare –

+0

@Noel: La convenzione di codifica del trattino basso non è sufficiente? Io odio seriamente le parole chiave 'this': P – Thorarin

+0

Underscore è ** non ** convenzione in Java –

1

Preferisco la seconda, solo perché rende chiaro al lettore ed è coerente poiché è necessario quando il parametro e il campo hanno entrambi lo stesso nome (quando è necessario in modo da differenziare ciò che viene impostato). Non c'è alcuna differenza funzionale tra i due in questo esempio, però.

1

this è esplicito e per questo motivo è preferito da molti. In alcuni casi, tuttavia, la differenza è significativa. per esempio. una variabile membro e una variabile locale con lo stesso nome.

Un esempio un po 'forzato, ma si ottiene l'idea.

2

Quando si utilizzano i setter in Java, this può essere utile per uscire dall'ambito della variabile corrente. Se invece avessi

private String bar = ""; 

public void fooSetter(String bar){ 
    this.bar = bar 
} 

che avrebbe stabilito correttamente la variabile di classe al posto di quella funzione variabile

1

vostri clienti dovrebbero essere

setFoo(String foo) 

e

public String getFoo() 

a conformarsi alle convenzioni javabean.

Se il nome di riferimento nel setter (foo) è uguale alla proprietà della classe, è necessario utilizzare 'this' per essere espliciti.

1

Come è stato detto, non è ambiguo, ma preferisco senza usare questo pure.

Vorrei andare con qualcosa di simile che impedisca anche l'ambiguità dando nomi più espliciti allo scopo delle variabili.

public void setBar(String newBar) 
{ 
    bar = newBar; 
} 

Questa sarebbe la mia prima scelta, la seconda sarebbe quella di utilizzare il questo, non vorrei prendere in considerazione le sottolineature.

3

I diversi stili sono principalmente causati da ciò che un programmatore ha fatto prima di Java, quali standard di codifica sono presenti in azienda, ecc.

lo stile desiderato è quello di utilizzare:

public class A { 
      private Type property; 

      public Type getProperty(){ 
       return this.property; 
      } 

      public void setProperty(Type property){ 
       this.property = property; 
      } 
    } 

Questa è una specie di stile best-practice ed è conforme allo standard JavaBeans.

2

È uno più desiderabile rispetto agli altri?

dipende dalla portata che si desidera usare-

public class myClass{ 

    private int number=5; 

    private void setNumbers(float number){ 
     number=1; // refers to local variable (float) 
     this.number=2; // refers to class variable (int) 
    } 

} 

Mi piace usare "this.variable" ogni volta che mi riferisco a una variabile di classe, si noterà che Eclipse sarà anche evidenziare variabili di classe in blu dove le variabili locali rimangono nere e ciò può essere utile.

Problemi correlati