Java Rule Round-Up

[Joe Nguyen]

(#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]

What about this:

public class Test
{
    private intnum;
    public Test(int num)
    {
        this.num = num;
    }
    
    public void changeOther(Test otherTest)
    {
        otherTest.num = -12;
    }
    
    public static void main(String args[])
    {
        Test test1 = new Test(3);
        Test test2 = new Test(555);
        
        System.out.println("test2.num before: " + test2.num);
        test1.changeOther(test2);
        System.out.println("test2.num after: " + test2.num);
        
    }
}

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

[Joe Nguyen]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[Stefan Wagner]

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.

[Joe Nguyen]

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]

I cannot agree.
The typical situation is comparTo

public class Person
{
    private int size;
    private String name;
    private Decimal salary;
 
    public int compareTo (Object o)
    {
         // errorchecking left out
         Person second = (Person) o;
 
         // side-effect surprising:
         second.salary = 0;
         // second.setSalary (0);
 
         // fast access - no bad idea:
         if (size == second.size) return name.compareTo (second.name);
         return size - second.size;
    }
    // ... setSalary () ...
}

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.