Question on private member variable access

[yilmaz uksal]

Hi

I was reading Head First Object Oriented Analysis and Design Book. Some code example confused me. It compiles, but there is something confusing about it.

Here is the code from the book.

public class Bark {

private String sound;

public Bark(String sound) {
this.sound = sound;
}

public String getSound() {
return sound;
}

public boolean equals(Object bark) {
if (bark instanceof Bark) {
Bark otherBark = (Bark)bark;
if (this.sound.equalsIgnoreCase(otherBark.sound)) {
return true;
}
}
return false;
}
}

What seems weird to me is that sound is a private member variable. In the equals method, I understand that 'this.sound' refers to the object whose equals method is called and I know an object can access its private members in its own methods. What I don't understand is that 'otherBark.sound'. Shouldn't 'otherBark.getSound()' method be used because we use a reference here and sound member variable has private access.

[Campbell Ritchie]

Private access means you can access anything in the same class. The otherBark object is in the same class.

[yilmaz uksal]

Which one is better to use in your opinion from an object oriented design perspective? otherBark.sound or otherBark.getSound()?

[Campbell Ritchie]

I would use otherBark.sound, because it is in the same class. That is what is normally used. There is no need to use a method inside the same class.

[Paul Clapham]

There's a tricky design problem here.

The otherBark variable may be referring to an object of some subclass of Bark... let's call it VoodooBark just for example. This subclass may have overridden the getSound() method to do something different than just returning the sound variable. (Especially if it's a "voodoo" class...)

So now what? When is a Bark object "equal to" a VoodooBark object? When their sound variables are the same? Or when the value returned by getSound() is the same? Bear in mind that when you're writing the Bark class, all you know is that somebody might write subclasses of it. And that they might override the getSound() method.

And when is a VoodooBark object equal to a Bark object? Remember that VoodooBark might also have overridden the equals() method, and it might do something completely different than what Bark's equals() method does. If that happens then b.equals(vb) might return true and vb.equals(b) might return false. This is a Bad Thing™, but there really isn't much you can do about it when you write your Bark class.

So what I'm saying is, no matter what you do, bad things can happen and they are somewhat beyond your control. I would go along with Campbell and just use the variable. Then at least your class is consistent. Let the people who write the subclasses deal with the ugly problems that might arise.