Czy możesz wyjaśnić tę rzecz o enkapsulacji?

Question

W odpowiedzi na pytanie, What is your longest-held programming assumption that turned out to be incorrect? jednego z błędnych założeniach było:

że prywatne zmienne składowe były prywatny do instancji, a nie klasy .

(Link)

nie mogłem złapać to, co on mówi, może ktoś wytłumaczyć co jest źle/prawo o tym na przykładzie?

Answer 1

public class Example { 
    private int a; 

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

Podoba mi się to. Jak widać prywatne nie chroni członka instancji przed dostępem do niego przez inną instancję.

BTW, to nie jest tak źle, dopóki jesteś trochę ostrożny. Jeśli prywatne nie działałoby jak w powyższym przykładzie, byłoby niewygodne pisanie equals() i innych takich metod.

Answer 2

Przykład kodu (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; // <------------ 
    } 
} 

Jeżeli założenie „prywatne zmienne składowe są prywatne do instancji” były prawidłowe, oznaczona linia spowoduje błąd kompilatora, ponieważ pole other.value jest prywatny i część innego obiektu niż ten, którego metoda jest wywoływana.

Ale ponieważ w Javie (i większości innych języków, które mają koncepcję widoczności) private widoczność jest za klasą, dostęp do pola jest dozwolony dla całego kodu MutableInteger, nieistotny dla instancji użytej do jej wywołania.

Answer 3

Oto odpowiednik Michael Borgwardt's answer bo gdy jesteś nie stanie uzyskać dostęp do prywatnych pól drugiego obiektu:

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

Obecnie jest to znana programistów Ruby, ale robią to w Javie dla chwila. Wolę nie polegać na dostępie do prywatnych pól innego obiektu. Pamiętaj, że drugi obiekt może należeć do podklasy, która może przechowywać wartość w innym polu obiektu, w pliku lub bazie danych itp.