Can you explain this thing about encapsulation?

Question

In response to What is your longest-held programming assumption that turned out to be incorrect? question, one of the wrong assumptions was:

That private member variables were private to the instance and not the class.

(Link)

I couldn't catch what he's talking about, can anyone explain what is the wrong/right about that with an example?

Answer 1

public class Example {
  private int a;

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

Like this. As you can see private doesn't protect the instance member from being accessed by another instance.

BTW, this is not all bad as long as you are a bit careful. If private wouldn't work like in the above example, it would be cumbersome to write equals() and other such methods.

Answer 2

Example code (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; // <------------
    }
}

If the assumption "private member variables are private to the instance" were correct, the marked line would cause a compiler error, because the other.value field is private and part of a different object than the one whose equals() method is being called.

But since in Java (and most other languages that have the visibility concept) private visibility is per-class, access to the field is allowed to all code of the MutableInteger, irrelevant of what instance was used to invoke it.

Answer 3

Here's the equivalent of Michael Borgwardt's answer for when you are not able to access the private fields of the other object:

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

Nowadays this is familiar to Ruby programmers but I have been doing this in Java for a while. I prefer not to rely on access to another object's private fields. Remember that the other object may belong to a subclass, which could store the value in a different object field, or in a file or database etc.