This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Java in General and the fly likes Java Rule Round-Up Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "Java Rule Round-Up" Watch "Java Rule Round-Up" New topic
Author

Java Rule Round-Up

Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
(#80) Can one object access a private variable of another object of the same class?

"Answer:Yes...two objects of the same class could access each other's private data."

I don't think it is correct . It would be correct if two objects access a private class variable.
Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
What about this:

With the results:
test2.num before: 555
test2.num after: -12


SCJP 1.4<br /><a href="http://www.cise.ufl.edu/~sih" target="_blank" rel="nofollow">www.cise.ufl.edu/~sih</a>
Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
It 's a good example. Thanks Sayed.

Does it violate object encapsulation in which an object instance directly modifies private variable of another object instance? This would introduce unexpected side effect. What do you think?
Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
Hi,
I don't think this is a violoation of encapsulation(although some may disagree). The whole idea of encapsulation and data hiding is to prevent objects from modifying when they don't know exactly what they are dealing with. For example if I had a class that contained an int, this int would be private and I would make public get/set methods for it.
Assume that this class has a set of listeners associated with it that would need to be notified that its value has changed. Objects of different classes may not know about this but certainly objects of the same class know, so its ok to let them take care of it. In the sample that I provided you in the changeOther() method it would also have to notify those liseteners.
I hope this makes sense, and also hope that too many people won't disagree.

--
Sayed Hashimi
Randy Nichols
Greenhorn

Joined: Aug 30, 2003
Posts: 4
Originally posted by Sayed Ibrahim Hashimi:
Hi,
I don't think this is a violoation of encapsulation(although some may disagree). The whole idea of encapsulation and data hiding is to prevent objects from modifying when they don't know exactly what they are dealing with. For example if I had a class that contained an int, this int would be private and I would make public get/set methods for it.
Assume that this class has a set of listeners associated with it that would need to be notified that its value has changed. Objects of different classes may not know about this but certainly objects of the same class know, so its ok to let them take care of it. In the sample that I provided you in the changeOther() method it would also have to notify those liseteners.
I hope this makes sense, and also hope that too many people won't disagree.

--
Sayed Hashimi


But wouldn't that also be a reason for wanting it to NOT be visible, so I could put "setter" and "getter" methods on the object where I'd put the notify code, and make sure others don't access the private members without my knowing?
Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
Originally posted by Randy Nichols:

But wouldn't that also be a reason for wanting it to NOT be visible, so I could put "setter" and "getter" methods on the object where I'd put the notify code, and make sure others don't access the private members without my knowing?

I think that you have to view this from a class perspective not an instance perspective. The creators of the class should know the constraints that are implemented within the class, and should have the freedom to not be required to use get/set like outside classes do.

With that being said they should also notify anyone who is interested. I would agree that it is better practice to use the get/set.
[ March 24, 2005: Message edited by: Sayed Ibrahim Hashimi ]
Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
Let forget about class perspective for a moment and discuss about general OO practice.

Suppose there is a class Person and let create two instances of the class Person. One is John and the other is Michelle. It would not be right to let John directly modifies Michelle's favorite sport without letting michelle knows (assume favoriteSport is a private variable of class Person).

As long as direct access to private variable is permitted, the other object does not need/want to invoke getter/setter method.
Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
Originally posted by Joe Nguyen:
Let forget about class perspective for a moment and discuss about general OO practice.

Suppose there is a class Person and let create two instances of the class Person. One is John and the other is Michelle. It would not be right to let John directly modifies Michelle's favorite sport without letting michelle knows (assume favoriteSport is a private variable of class Person).

As long as direct access to private variable is permitted, the other object does not need/want to invoke getter/setter method.


This doesn't seem right because you are bringing the human aspect into it. I would hate if someone else decided what my favorite sport is (its chess in case you were wondering).
But what if we are dealing with a linked list when items are moved around it may be necessary to change the references for other members of the list and I don't think that they should be required to make the method calls to do such, especially if you are dealing with large lists and preformace is a great concern and seeing how it is the code that lies in the class doing such why not let them change it? The idea here is to dis-allow other types of objects access to private data not code within the same class.
Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
I don't see how linklist could be an example in this case. If I have a read-only variable in an object which is stored in a linklist, I certainly don't want other objects of the same class to modify the read-only variable.
Rick Goldstein
Greenhorn

Joined: Oct 10, 2003
Posts: 21
Personally, the only reason I would generally directly access a private field from another instance of the same class would be in something like a copy constructor. If modifying a field has a side effect, I will probably have written the set method to perform that side effect (or have it call yet another method that handles the change). Then I typically even want the instance itself to use the setter--otherwise I have duplicate code snippets somewhere, and maintainability suffers.

In short, I treat private fields as read-only from the perspective of other instances of the same class (and even then, only in limited circumstances).

Rick
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Interesting discussion. I don't think I liked the answer. Tough luck for me.

As the (ever controversial) Allen Holub says, one should think of an OO system in terms of objects and their interactions, not classes. Classes are just a convenience for the compiler; the design is objects. Anyhow, I'd prefer private to be truly private. Direct access to a variable in another object of the same class is nearly as bad as any other class. Some higher level behavior methods would be preferable even to setters.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

I agree to Sayeds argument.

The argument of favorite sports isn't counting.
Whether Joe is calling:

michelle.favoriteSport = "java";
or
michelle.setFavoriteSport ("java");
- where is the difference?
The writer of 'Person' has total access to the class, and may implement whatever he wants though.

Direct access is useful for performance, when implementing 'compareTo'. Well, a clever compiler could optimize this on his own.

I was surprised by the interpretation of 'private member access' too, when I heared about it the first time, and I guess, it's the fault of some popular introductions to OO-Concepts, which tell you about security by encapsulation in a too popular manner.
You may avoid risks from other programmers (classes), using your Objects, by restricting the access, but not your own class.


http://home.arcor.de/hirnstrom/bewerbung
Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
michelle.favoriteSport = "java";
or
michelle.setFavoriteSport ("java");
- where is the difference?
The writer of 'Person' has total access to the class, and may implement whatever he wants though.


The difference is at the place where the writer of 'Person' is not the same as the creator of the 'Person' instance. If the Person class is public, everyone can create instances of the class; this is where unwanted side effects may take place.
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

I cannot agree.
The typical situation is comparTo


If the Person class is public, everyone can create instances of the class; this is where unwanted side effects may take place.

Yes - but independent from the question of accessing membervariables instantly, or via a methodcall.

The sideeffect happens in the class.
If you don't like it, don't use that class.
 
GeeCON Prague 2014
 
subject: Java Rule Round-Up