2010-04-02 5 views
10

So che le variabili di istanza private sono accessibili tramite il metodo Getter e setter pubblici.Java - È necessario accedere alle variabili di istanza private nei costruttori tramite il metodo getter e setter?

Ma quando genero i costruttori con l'aiuto di IDE, inizializza direttamente le variabili di istanza invece di inizializzarle attraverso i loro metodi di setter.

Q1. Quindi dovrei cambiare il codice generato da IDE per i costruttori per inizializzare tali variabili di istanza attraverso i loro metodi setter.

Q2. Se sì, allora perché IDE non genera codice costruttori in quel modo?

============================= MODIFICATO ================ =======================

  • io uso Eclipse e Netbeans IDE

  • e 'una domanda di carattere generale. Ma come richiesto da @Lords, la risposta dipende dal fatto che il nostro costruttore sia pubblico o protetto o che il pacchetto sia privato o privato?

+0

I tuoi costruttori sono pubblici, privati ​​o qualcos'altro? – Pops

+0

@Lord Ho modificato la mia domanda –

+0

E ho modificato la mia risposta. (In realtà due modifiche in rapida successione.) – Pops

risposta

12

È necessario mai chiamare un metodo non finale da un costruttore.Un costruttore di classi viene utilizzato per inizializzare un oggetto e l'oggetto non è in uno stato coerente finché non viene restituito il costruttore. Se il costruttore chiama un metodo non finale che viene successivamente sostituito da una sottoclasse, è possibile ottenere risultati strani e inattesi perché l'oggetto non è completamente inizializzato quando viene chiamato il metodo sottoposto a override.

Consideriamo questo esempio forzato:

class A { 
    private int x; 

    public A() { 
     setX(2); 
    } 

    public void setX(int x) { 
     this.x = x; 
    } 

    public int getX() { 
     return x; 
    } 
} 

class B extends A { 
    private int number = 10; 

    @Override   
    public void setX(int x) { 
     // set x to the value of number: 10 
     super.setX(number); 
    } 
} 

public class Test { 
    public static void main(String[] args) { 
     B b = new B(); 
     // b.getX() should be 10, right? 
     System.out.println("B.getX() = " + b.getX()); 
    } 
} 

L'uscita di questo programma è:

B.getX() = 0 

La ragione è che B s' number membro non è inizializzato al momento setX è chiamato, così viene utilizzato il suo valore predefinito di 0.

This article ha una spiegazione più approfondita, così come Java efficace.

1

Dipende. Se i tuoi setter/getter stanno semplicemente accedendo ai membri, devi accedervi direttamente. Se hai anche del codice insieme ad esso, usa setter.

+0

ok ma non sarebbe meglio usare setter anche se i setter li stanno semplicemente impostando direttamente in modo da seguire Encapsulation e rendere più facile aggiungere del codice in setter in futuro (se necessario)? –

+0

Bene, allora non sarebbe più un setter. Dovresti anche considerare che da un punto di vista orientato agli oggetti i setter non sono orientati agli oggetti (quale oggetto in natura ha un "setter"?) – Searles

0

Si dovrebbe decidere quali campi si inizializzeranno con il costruttore e quali initalizzare con un setter. (entrambi sono possibili) Preferisco usare il costruttore solo il più possibile e spesso non ho setter.

Questo dovrebbe essere configurabile/selezionabile in IDE. Senza conoscere il tuo IDE non c'è modo di sapere perché funziona come fa.

2

I costruttori sono per l'inizializzazione. Inizializza le variabili di istanza private direttamente nel costruttore. I metodi definiscono il comportamento di un oggetto. Il comportamento si verifica dopo l'istanziazione/inizializzazione. Manipola lo stato delle tue variabili di istanza con i tuoi metodi setter. Questo è il classico pensiero OOP e probabilmente perché il tuo IDE sta generando il codice che fa.

0

Buone risposte. Voglio solo aggiungere che Eclipse (quello che uso spesso) ha dei template, che puoi modificare per generare il tuo codice nel modo desiderato. Potrebbe aiutare a regolare il codice in base alle proprie esigenze.

PS. Preferisco usare setter e getter. Proprio come un'abitudine, mantiene il codice coerente, mi sembra che sarà più facile leggere per qualcun altro se manterrò le abitudini su tutto il codice.

0

Prima di tutto initialization != setters (almeno non sempre)

Ma IDE stanno solo giocando bello, con un tempo venerati JavaBean modello di progettazione Assumendo modifiche alle proprietà dovrebbero accadere tramite setter.

Quindi, è una questione di design. Se le tue classi rappresentano oggetti di puro valore, nessun danno nell'inizializzazione tramite = Ma se le tue classi hanno il potenziale di diventare un JavaBean la cui modifica delle proprietà è più di un semplice init o assegnazione, vai con le chiamate set*.

0

Le variabili di istanza private di una classe devono essere dichiarate (credo necessario) all'esterno di qualsiasi costruttore di classi. Se potessi suddividere parte della tua domanda in due parti:

Q1) Se le variabili di istanza vengono inizializzate quando viene creata un'istanza di una classe, a differenza delle variabili locali, perché preoccuparsi di eseguire il lavoro aggiuntivo all'interno di un determinato costruttore di classi (?).

A1) Anche se non è necessario inizializzare le variabili di istanza (stringa privata someString; il valore predefinito è null ed è legale), un motivo per farlo è che l'impostazione predefinita assegnata dal compilatore potrebbe non essere il valore desiderato, oppure peggio, errato (che il compilatore dovrebbe prendere).

Q2) Supponendo la parte sopra, qual è il significato di ottenere; impostato; proprietà?

A2) A parte il fatto che sono facili e più eleganti che un metodo equivalente, le proprietà possono essere utilizzate in qualsiasi momento all'interno della classe (ovviamente), possono essere utilizzate come assegnazioni semplici o contenere codice aggiuntivo (qualcuno ha già dichiarato questo per la convalida delle informazioni), e infine i dati sono autonomi all'interno della classe e quindi più facili da eseguire il debug.

Tutto ciò detto, si può avere una ragione perfettamente valida per fare le cose in modo diverso da quello che dice un libro o qualcun altro. Ci sono sempre delle accettazioni alla "regola (e)", e dovresti codificare di conseguenza.

Problemi correlati