Puoi spiegare questa cosa sull'incapsulamento?

Question

In risposta alla domanda What is your longest-held programming assumption that turned out to be incorrect?, una delle ipotesi sbagliate era:

Che variabili membro private erano privato all'istanza e non la classe .

(Link)

Non riuscivo a cogliere ciò che sta parlando, chiunque può spiegare che cosa è sbagliato/ragione su questo con un esempio?

Answer 1

public class Example { 
    private int a; 

    public int getOtherA(Example other) { 
    return other.a; 
    } 
} 

In questo modo. Come puoi vedere, il privato non protegge il membro dell'istanza dall'accesso da un'altra istanza.

BTW, questo non è niente male finché si è un po 'attenti. Se privato non funzionasse come nell'esempio precedente, sarebbe ingombrante scrivere equals() e altri metodi simili.

Answer 2

codice di esempio (Java):

public class MutableInteger { 
    private int value; 

    // Lots of stuff goes here 

    public boolean equals(Object o) { 
     if(!(o instanceof MutableInteger)){ return false; } 
     MutableInteger other = (MutableInteger) o; 
     return this.value == other.value; // <------------ 
    } 
} 

Se l'ipotesi "variabili membro private sono private all'istanza" fosse corretta, la linea tracciata causerebbe un errore di compilazione, perché il campo other.value è privato e parte di un oggetto diverso da quello in cui viene chiamato il metodo equals().

Ma dal momento che in Java (e nella maggior parte delle altre lingue con il concetto di visibilità) private visibilità è per classe, l'accesso al campo è consentito a tutto il codice dello MutableInteger, irrilevante di quale istanza è stata utilizzata per invocarlo.

Answer 3

Ecco l'equivalente di Michael Borgwardt's answer per quando si è non in grado di accedere ai campi privati ​​della altro oggetto:

public class MutableInteger { 
    private int value; 

    // Lots of stuff goes here 

    public boolean equals(Object o) { 
     if(!(o instanceof MutableInteger)){ return false; } 
     MutableInteger other = (MutableInteger) o; 
     return other.valueEquals(this.value); // <------------ 
    } 

    @Override // This method would probably also be declared in an interface 
    public boolean valueEquals(int oValue) { 
     return this.value == oValue; 
    } 
} 

Oggi questo è noto a programmatori Ruby, ma io ho fatto questo in Java per un po. Preferisco non fare affidamento sull'accesso ai campi privati ​​di un altro oggetto. Ricorda che l'altro oggetto può appartenere a una sottoclasse, che potrebbe memorizzare il valore in un campo oggetto diverso, o in un file o database, ecc.