Perché sono le variabili di istanza in Java sempre privato?

Io sono newbie di Java e sto imparando circa l’incapsulamento e visto un esempio in cui le variabili di istanza sono dichiarati come privato in una classe.

http://www.tutorialspoint.com/java/java_encapsulation.htm

Ho 2 interrogazioni:

  1. Perché sono le variabili di istanza private? Perché non pubblica?
  2. Che se le variabili di istanza sono rese pubbliche e accessibili direttamente? Vediamo di tutti i vincoli?

Si può spiegare con un esempio di ciò che si andrà male nel caso in cui le variabili di istanza sono dichiarate pubbliche in una classe in Java?

  • Si può spiegare con un esempio di ciò che si andrà male nel caso in cui le variabili di istanza sono dichiarate pubbliche in una classe in Java ?
  • Immagine se un campo non devono mai essere null. Se si dispone di un setter metodo si potrebbe verificare per null e getta e IllegalArgumentException se null è mai passata. Tuttavia, se il campo è public rispetto a qualsiasi utente della classe è possibile impostare il campo a qualsiasi valore compreso null. Allora il vostro codice potrebbe ottenere un NullPointerException perché era sempre in attesa sul campo di non essere mai null.
  • Il link che hai postato ha un “Vantaggi dell’Incapsulamento” sezione, alla fine, che sarebbe utile per guardare.
  • Non sempre privato. Di solito è così, ma non sempre.
InformationsquelleAutor Deepak | 2011-10-01

 

9 Replies
  1. 36

    Le variabili di istanza sono rese private per forzare gli utenti di quelle di classe per utilizzare i metodi di accesso.
    Nella maggior parte dei casi ci sono di pianura getter e setter, ma altri metodi possono essere utilizzati come bene.

    Uso di metodi che consentono, per esempio, per limitare l’accesso di sola lettura, cioè un campo potrebbe essere letti, ma non è scritto, se non c’è un setter. Che non sarebbe possibile se il campo è stato pubblico.

    Inoltre, si potrebbe aggiungere alcuni controlli o le conversioni per l’accesso al campo, il che non sarebbe possibile con un semplice accesso a un campo pubblico. Se era un campo pubblico e si sarebbe poi come per forza, tutte con accesso tramite un metodo che esegue controlli aggiuntivi, etc. Devi cambiare tutti gli usi di quel campo. Se renderlo privato, devi solo cambiare i metodi di accesso in seguito.

    Se phone è stato privato:

    Considerare questo caso:

    class Address {
      private String phone;
    
      public void setPhone(String phone) {
        this.phone = phone;
      }
    }
    
    //access:
    Address a = new Address();
    a.setPhone("001-555-12345");

    Se abbiamo iniziato con la classe e, successivamente, è necessario per l’esecuzione di controlli su un numero di telefono (ad esempio, alcuni di lunghezza minima, cifre etc.) devi solo cambiare il setter:

    class Address {
      private String phone;
    
      public void setPhone(String phone) {
        if( !isValid( phone) ) { //the checks are performed in the isValid(...) method
         throw new IllegalArgumentException("please set a valid phone number");
        }
    
        this.phone = phone;
      }
    }
    
    //access:
    Address a = new Address();
    a.setPhone("001-555-12345"); //access is the same

    Se phone stato il pubblico:

    Qualcuno potrebbe impostare phone come questo e non si poteva fare nulla:

    Address a = new Address();
    a.phone="001-555-12345";

    Se si desidera forzare la convalida controlli che devi fare è privato e chi ha scritto le righe sopra sarebbe necessario modificare la seconda riga di questo:

    a.setPhone("001-555-12345");

    Così non si poteva solo aggiungere i controlli senza la rottura di un altro codice (non compilare più).

    Inoltre, se è possibile accedere a tutti i campi e le proprietà di una classe attraverso metodi di mantenere coerenza e l’utente non deve preoccuparsi se la proprietà viene archiviata (cioè è un esempio di campo) o calcolati (ci sono solo metodi e non campi di istanza).

    • Thomas,si Potrebbe rivedere il vostro esempio.Poiché penso che la Stringa di telefono nel primo frammento di codice dovrebbe essere pubblico.!!!!
    • Guarda bene a me, con l’avvertenza che nel commento if phone was public.
    • Ho riformattato la risposta a rendere la condizione chiara: l’esempio mostra quello che dovrebbe apparire come (phone privati) e l’ultima parte di ciascun blocco deve mostrare ciò che potrebbe accadere se è stato il pubblico, invece.
    • >Che non sarebbe possibile se il campo è stato pubblico. – Come su final modificatore?
    • si potrebbe utilizzare un public final campo di sola lettura costante, ma in molti casi il campo non è una costante. Spesso sola lettura colpisce solo l’interfaccia, cioè gli utenti dell’oggetto non può modificare il campo. Internamente, tuttavia, l’oggetto potrebbe aggiornare il campo, ad esempio facendo alcuni calcoli, e che non sarebbe possibile con final campi.
    • Perché è necessario forzare gli utenti di quelle di classe a utilizzare i metodi per accedervi? Perché “Indirizzo di un = nuovo Indirizzo(); a.telefono=”001-555-12345″;” bad?
    • hai letto tutta la mia risposta? In realtà ho già risposto a questo, ma io a ribadire: se si decide in seguito all’aggiunta di alcuni convalida (diciamo il numero di telefono deve corrispondere al modello xxx-xxx-xxxxx) si potrebbe aggiungere che il setter invece di cambiare ogni posizione nel codice che chiama direttamente a.phone="whatever" (nota che “a prescindere” è un segnaposto e non significa che bisogna sempre utilizzare un valore letterale, potrebbe anche essere l’input dell’utente).

  2. 10

    Non hanno di essere privata, ma dovrebbero essere. Un campo è un dettaglio di implementazione – in modo si dovrebbe tenere privato. Se si desidera consentire agli utenti di recuperare o impostare il suo valore, proprietà di farlo (metodi get e set) – questa applicazione consente di eseguire in modo sicuro (ad esempio la convalida dell’input) e permette anche di modificare i dettagli di implementazione (ad esempio, di delegare alcuni dei valori per gli altri oggetti, ecc), senza perdere la compatibilità.

    • Ciao Jon.Mi può dare un esempio.che cosa succede se ho impostato il pubblico.
    • Quindi questo significa che si perde un sacco di controllo su di essa – non è possibile modificarne il nome o il modo in cui viene utilizzata, o del filo di sicurezza, ecc, nel futuro, perché il resto del mondo può solo leggere ogni volta che lo vorranno. Non è possibile renderlo modificabile internamente senza anche di lasciare tutti gli altri di cambiare con nessuna validazione, etc. Per la finale di variabili non è come male, ma è ancora una buona idea IMO.
    • Ciao Jon,si Potrebbe si prega di fornire un codice snippetexample dove non riesce.sarebbe più chiaro
    • per uno, non riesce appena hai qualche altro codice che utilizza la variabile di istanza (i dettagli di implementazione) e vuoi cambiare niente (l’implementazione). Avendo funzioni di accesso e mutator (getter e setter) siete liberi di modificare l’implementazione in qualsiasi modo si desidera, finché si mantiene il contratto di tipo pubblicamente di fronte a interfaccia.
    • Non è una questione di codice in mancanza – è una questione di essere un cattivo design.
  3. 7

    Primo, non è vero che tutte le variabili di istanza private. Alcuni di loro sono protetti, di cui conserva ancora l’incapsulamento.

    L’idea generale di incapsulamento è che una classe non deve esporre il suo stato interno. Si consiglia di utilizzare soltanto per lo svolgimento dei suoi metodi. Il motivo è che ogni classe ha un cosiddetto “spazio di stato”. Che è, un insieme di valori possibili per i suoi campi. È possibile controllare il suo stato di spazio, ma se si espone, altri potrebbero metterlo in uno stato non valido.

    Per esempio, se si dispone di due campi booleani, e la classe è in grado di funzionare correttamente solo in 3 casi: [false, false], [false, true], e [true, false]. Se si fanno i campi pubblici, un altro oggetto può impostare [true, true], non conoscendo i vincoli interni, e il successivo metodo chiamato l’oggetto a cui si trigger risultati imprevisti.

    • ,Si può spiegare con un esempio per questa affermazione “ma se si espone, altri potrebbero metterlo in uno stato non valido.”
    • possiamo avere un esempio di codice
  4. 4

    Fare le variabili di istanza, pubblico o privato, è un design compromesso la
    designer rende la dichiarazione di classi. Facendo istanza
    le variabili pubbliche, si espongono i dettagli dell’implementazione della classe,
    fornendo in tal modo una maggiore efficienza e la brevità di espressione in
    spese di ostacolare i futuri interventi di manutenzione. Da
    nascondere i dettagli di implementazione interna di una classe, si ha la
    il potenziale per cambiare l’implementazione della classe in futuro
    senza la rottura di qualsiasi codice che utilizza la classe.

    Oracle Carta Bianca

  5. 2

    Come è stato sottolineato da diversi utenti già, le variabili di istanza non deve essere private, ma sono di solito almeno non fatto public, al fine di mantenere l’incapsulamento.

    Ho visto un esempio in (credo) la Pulizia del Codice, che ben illustra questo. Se ricordo bene, si trattava di un numero complesso (come in a+bi) tipo; in ogni caso, qualcosa di molto simile, non ho il libro a portata di mano. Esposto metodi per ottenere il valore della parte reale e immaginaria, nonché un metodo per impostare il valore dell’istanza. Il grande vantaggio di questo è che permette l’attuazione di essere completamente sostituito senza infrangere alcuna consumatori del codice. Per esempio, i numeri complessi possono essere memorizzati su una delle due forme: come coordinate sul piano complesso (a+bi), o in forma polare (φ e |z|). Mantenere l’interno del formato di archiviazione di un dettaglio di implementazione permette di cambiare avanti e indietro, mentre ancora di esporre il numero su entrambe le forme, lasciando così l’utente della classe scegliere a seconda di quale è più conveniente per l’operazione sono attualmente in esecuzione.

    In altre situazioni, si può avere un set di campi correlati, come il campo x deve avere determinate proprietà se il campo y cade all’interno di un determinato intervallo. Un semplice esempio potrebbe essere quello di x deve essere compresa nel range y attraverso y+z, per i valori numerici e arbitrario valore z. Esponendo le funzioni di accesso e dei setter, è possibile applicare questo rapporto tra i due valori; se si espongono le variabili di istanza direttamente, invariante crolla immediatamente, in quanto non è possibile garantire che qualcuno non uno ma non l’altro, o, in modo che l’invariante non regge più.

    Naturalmente, considerando la riflessione, è ancora possibile accedere ai membri non dovrebbero, ma se qualcuno sta riflettendo classe di accedere a soci privati, avrebbero fatto meglio a rendersi conto di quello che stanno facendo molto bene rompere le cose. Se si utilizza l’interfaccia pubblica, si potrebbe pensare che tutto è a posto, e poi si finisce con il brutto bug, perché inconsapevolmente non aderire pienamente all’attuazione dettagli della particolare implementazione.

  6. 1

    Tradizionale progettazione Object-Oriented, in una classe vi incapsulare sia i dati (variabili) e il comportamento (metodi). Avendo i dati privati vi darà la flessibilità di come il comportamento è implementato, così, per esempio, un oggetto può memorizzare un elenco di valori e di avere un getAverage() metodo che calcola e restituisce la media di questi valori. In seguito, si potrebbe ottimizzare la cache e la calcolata la media della classe, ma il contratto (ad esempio, i metodi) non avrebbe bisogno di cambiare.

    È diventato più popolare degli ultimi anni (in meglio o in peggio) per utilizzare anemico modelli di dati, in cui una classe è altro che un mucchio di campi e corrispondente getter e setter. Direi che in questo disegno si sarebbe meglio con i campi pubblici, dal momento che i metodi getter e setter fornire alcuna reale incapsulamento, ma solo di ingannare l’utente a pensare che si sta facendo reale OO.

    AGGIORNAMENTO: L’esempio riportato nel link in questione è un perfetto esempio di questo degeneri incapsulamento. Mi rendo conto che l’autore sta cercando di fornire un semplice esempio, ma così facendo, non riesce a trasmettere alcun reale beneficio di incapsulamento (almeno non nel codice di esempio).

  7. 0
    1. Perché se si modifica la struttura della classe (rimozione di campi etc.); sarà causa di bug. Ma se si dispone di un getX() metodo è possibile calcolare il valore necessario (se il campo è stato rimosso).

    2. Avete il problema, quindi, che la classe non so se qualcosa è cambiato e non può garantire l’integrità.

  8. 0

    Ben talmente semplice mantenere aggiornati i campi privati ha molti vantaggi, come suggerito sopra.
    Il prossimo livello migliore è tenerli pacchetto privato utilizzando java livello di accesso predefinito.

    Livello predefinito evitare confusione nel proprio codice, e impedisce che i vostri clienti del codice di impostazione di valori non validi.

  9. 0

    Utente della classe

    Noi, che utilizza ide come eclipse, netbins…..
    visto che ci suggeriscono per il metodo pubblico, quindi se il creatore di classe di metodi getter e setter per privati variabile di istanza non è necessario memorizzare il nome della variabile. basta scrivere impostare premere ctrl+spazio che si stanno ottenendo tutti i setter metodo creato dal creatore di quella classe e scegliere il metodo desiderato per impostare il valore della variabile.

    Per il creatore di classe

    A volte è necessario specificare un po ‘ di logica per impostare il valore della variabile.
    “supponiamo di avere una variabile di tipo integer che dovrebbe archiviare 0

Lascia un commento