¿Puedes explicarme esto sobre la encapsulación?

Question

En respuesta a la pregunta What is your longest-held programming assumption that turned out to be incorrect?, una de las suposiciones erróneas fue:

que las variables miembro privadas eran privado a la instancia y no a la clase .

(Link)

no pude captar lo que está hablando, ¿alguien puede explicar lo que es el mal/razón en eso con un ejemplo?

Answer 1

public class Example { 
    private int a; 

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

Me gusta. Como puede ver, privado no protege al miembro de la instancia del acceso a otra instancia.

Por cierto, esto no es tan malo, siempre y cuando tenga un poco de cuidado. Si private no funciona como en el ejemplo anterior, sería engorroso escribir equals() y otros métodos similares.

Answer 2

Código de ejemplo (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; // <------------ 
    } 
} 

Si el supuesto "variables miembro privadas son privadas a la instancia" eran correctas, la línea marcada provocaría un error de compilación, porque el campo other.value es privada y parte de un objeto diferente al que se llama al método equals().

Pero como en Java (y la mayoría de los otros idiomas que tienen el concepto de visibilidad) private la visibilidad es por clase, el acceso al campo está permitido a todos los códigos MutableInteger, independientemente de qué instancia se utilizó para invocarlo.

Answer 3

Aquí es el equivalente de Michael Borgwardt's answer para cuando esté no acceder a los campos privados de otro objeto:

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; 
    } 
} 

Hoy en día esto es familiar para los programadores de Ruby, pero he estado haciendo esto en Java para Un rato. Prefiero no confiar en el acceso a los campos privados de otro objeto. Recuerde que el otro objeto puede pertenecer a una subclase, que podría almacenar el valor en un campo de objeto diferente, o en un archivo o base de datos, etc.