Question

The following code works & runs perfectly.

public class Complex {

private int real, imag;

Complex(int r, int i) {
    real = r;
    imag = i;
}

public static Complex add(Complex c1, Complex c2) {
    return new Complex(c1.real + c2.real, c1.imag + c2.imag);
}

public String toString() {
    return real + "+i" + imag;
}

public static void main(String[] args) {

    Integer.parseInt("5");
    System.out.println(Complex.add(new Complex(2, 3), new Complex(3, 4)));

}

}

Now according to Object oriented design model, private instance members shouldn’t be accessed through a object reference (which has been done here by c1.real ).

So, in that sense,there should be compiler error. But it doesn’t object.

Now according to my understanding it’s allowed because

1. c1.real code is written in the body of the private class Complex class itself.

2. Developer of Complex class should have access to all instance members [be it private,protected whatever] when accessing through an object reference, since Developer knows very well what he’s doing unlike any third party. That’s why object oriented model model isn’t followed here.

Can anyone suggest a better explanation about why c1.real code is allowed here?

Answer 1

The short answer is that because that’s the way Java defined the private access modifier.

The longer answer is that they probably assumed that strict encapsulation only makes sense above source file level, so even an inner class can access private members of its outer class (and vice versa): it simply makes no sense to hide members within the same source file. If you’ve got access to the source file of a class, you can easily modify any access modifiers anyway.

(Although the inner-outer class thing is achieved via synthetic accessors, but they’re almost completely transparent.)