Java Help - Question regarding Java's OOP implementation.

Author

Question regarding Java's OOP implementation.

cwsummers@kottonvan.com

2005-11-15, 7:57 am

According to Wikipedia, one of the core concepts of OOP is
Encapsulation; being defined as follows: "ensuring that users of an
object cannot change the internal state of the object in unexpected
ways; only the object's own internal methods are allowed to access its
state. Each object exposes an interface that specifies how other
objects may interact with it. Other objects will rely exclusively on
the object's external interface to interact with it." Not that I
regard Wikipedia's definition of OOP as the leading authority, it just
happens to be handy and provides a definition that fits my own ideas.
On to the question; If I create a class called AClass and inside
declare a class level variable with the private modifier and some other
methods, e.g.

public class AClass {

private int number;

public AClass(int num) {
number = num;
}

public void setAnotherAClass(AClass anotherAClass, int num) {
anotherAClass.number = num;
}

public int getAnotherAClass(AClass anotherAClass) {
return anotherAClass.number;
}

public void display() {
System.out.println("Number: " + number);
}
}

And a class to test AClass:

public class Test {

public static void main(String[] args) {

AClass one = new AClass(1);
AClass two = new AClass(2);

one.display();
two.display();

one.setAnotherAClass(two, 3);
two.display();
}
}
I would expect the compiler first to complain that number has private
access in AClass... Barring that I'm not sure what I'd expect it to
complain about, but something doesn't seem right. Child classes
derived from AClass were not able to make changes to objects of type
AClass which is what I would expect. But because one and two are
distinct objects the fact that they belong to the same class shouldn't
mean they can change each other's private instance variables. I
wasn't able to find anything directly relating to the question in an
hour or so of Googling. I also read through Java's tutorials on OOP to
see if they had anything specific to say, which they did not.

Thank you for your time and ideas.

Carl Summers

Ingo R. Homann

2005-11-15, 7:57 am

Hi,

what you proved with your code is the behaviour as it is specified.
'private' means that you cannot access the field from another class. It
does not say that anything about different instances of the same class.

In fact, the problem of accessability is not as one-dimensional as the
modifiers (from private to public) suggest. It has several dimensions:

(A) same class / subclass / different class
(B) same package / subpackage (which is not a concept that java supports
(*)) / different package
(C) inner class / different class
(D) same instance / different instance
(E) friend class (unknown by java as well) / non-friend class
(F) ...

Of course the different options are not completely orthogonal, but there
are much more potential combinations of access rights than just the 4
which java supports.

Ciao,
Ingo

(*) a.b.c has nothing to do with a.b.c.d

Thomas Hawtin

2005-11-15, 7:57 am

Ingo R. Homann wrote:
>
> (E) friend class (unknown by java as well) / non-friend class

Might be in Java SE 7. Currently keeping a large implementation secure
can involve reflection, wormhole and class loader hacks.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

Brendan Guild

2005-11-22, 4:01 am

cwsummers@kottonvan.com wrote in
news:1132044913.454573.181940@g47g2000cwa.googlegroups.com:
> I would expect the compiler first to complain that number has private
> access in AClass... Barring that I'm not sure what I'd expect it to
> complain about, but something doesn't seem right. Child classes
> derived from AClass were not able to make changes to objects of type
> AClass which is what I would expect. But because one and two are
> distinct objects the fact that they belong to the same class shouldn't
> mean they can change each other's private instance variables. I
> wasn't able to find anything directly relating to the question in an
> hour or so of Googling.

The point of encapsulation is not to keep the contents of each object
isolated as if it were a physical object with some kind of cell membrane
sheltering the internals from the outside world. The point is actually
this: We restrict who can access what parts of our objects so that the
code within the class has higher access rights, and therefore we have
only to look within the class if there is any kind of problem with those
restricted parts. Also, there's the abstraction, but that's not relevant
because once you are inside the class you are beyond the abstraction
already.

The real question is: Why do you think it should matter if the object we
are accessing happens to be 'this' or some other object of the current
class? We're giving this exact same code access to those internals
anyway. If something goes wrong with the private parts of that object,
it's the same code we'd be examining to find the problem.

Sponsored Links