Constructors + Information Hiding

Posted: 2005-10-12 20:48:00

java-programmer, Constructors + Information Hiding I have a random question about a constructor having access to a private
instance variable from an object of the same type.

Class:
public class VarTest {
private int x;
private String s;

public VarTest(){
x = 10;
s = "Testing";
}

public VarTest(int i, String str){
x = i;
s = str;
}

//I know why this would be a useful constructor,
// but why is this allowed if the instance variables for
// vt are private?????
public VarTest(VarTest vt){
x = vt.x;
s = vt.s;
}

public int getX(){
return x;
}

public String getS(){
return s;
}
}

Test Class:
public class Tester{
public static void main(String args[]){
VarTest var1, var2;

var1 = new VarTest(34, "Working?");
var2 = new VarTest(var1);

System.out.println("var2 - x:\t" + var2.getX());
//var2.getX() display 34... Why can is get that from var1?
}
}

Thanks In Advance Folks,
Josh

Posted: 2005-10-12 22:51:00

java-programmer >> Constructors + Information Hiding

Murph wrote On 10/12/05 08:48,:
> I have a random question about a constructor having access to a private
> instance variable from an object of the same type.
>
> Class:
> public class VarTest {
> private int x;
> private String s;
>
> public VarTest(){
> x = 10;
> s = "Testing";
> }
>
> public VarTest(int i, String str){
> x = i;
> s = str;
> }
>
> //I know why this would be a useful constructor,
> // but why is this allowed if the instance variables for
> // vt are private?????
> public VarTest(VarTest vt){
> x = vt.x;
> s = vt.s;
> [...]

"private" does not mean "private to a particular
instance," but "private to the class." Any method or
constructor in the class has access to all the private
members of all the class' instances, assuming it can
get hold of references to those instances.

This is not only useful, as you say, but downright
necessary in many cases. Consider writing an equals()
method for your VarTest class, one that considers
two VarTest objects "equal" if their x and s members
are equal. How could equals() make the decision if
it didn't have access to the other object's x?

--
email***@***.com

Posted: 2005-10-12 23:01:00

java-programmer >> Constructors + Information Hiding Eric Sosman wrote:
>
> Murph wrote On 10/12/05 08:48,:
>
>>I have a random question about a constructor having access to a private
>>instance variable from an object of the same type.
>>
>>Class:
>>public class VarTest {
>> private int x;
>> private String s;
>>
>> public VarTest(){
>> x = 10;
>> s = "Testing";
>> }
>>
>> public VarTest(int i, String str){
>> x = i;
>> s = str;
>> }
>>
>>//I know why this would be a useful constructor,
>>// but why is this allowed if the instance variables for
>>// vt are private?????
>> public VarTest(VarTest vt){
>> x = vt.x;
>> s = vt.s;
>>[...]
>
>
> "private" does not mean "private to a particular
> instance," but "private to the class." Any method or
> constructor in the class has access to all the private
> members of all the class' instances, assuming it can
> get hold of references to those instances.
>
> This is not only useful, as you say, but downright
> necessary in many cases. Consider writing an equals()
> method for your VarTest class, one that considers
> two VarTest objects "equal" if their x and s members
> are equal. How could equals() make the decision if
> it didn't have access to the other object's x?
>
Just like any other method : by calling the getters, which can by either
public or private.
I consider it quite ugly to call directly the attributes ; it violates
the encapsulation paradigm.

Posted: 2005-10-12 23:27:00

java-programmer >> Constructors + Information Hiding

Fabien Bergeret wrote On 10/12/05 11:01,:
> Eric Sosman wrote:
>>
>> "private" does not mean "private to a particular
>>instance," but "private to the class." Any method or
>>constructor in the class has access to all the private
>>members of all the class' instances, assuming it can
>>get hold of references to those instances.
>>
>> This is not only useful, as you say, but downright
>>necessary in many cases. Consider writing an equals()
>>method for your VarTest class, one that considers
>>two VarTest objects "equal" if their x and s members
>>are equal. How could equals() make the decision if
>>it didn't have access to the other object's x?
>>
>
> Just like any other method : by calling the getters, which can by either
> public or private.
> I consider it quite ugly to call directly the attributes ; it violates
> the encapsulation paradigm.

(I thought about writing something to forestall this
red herring, but foolishly imagined it wouldn't be dragged
across the trail ... Ah, well.)

The question was about what "private" access means,
not about how you would use or abuse whatever access you've
got. If "private" did in fact mean "private to the instance"
(which it doesn't; that was the crux of the O.P.'s question),
how, pray tell, could you invoke a private method -- whether
a getter or something else -- on any object other than "this"?

--
email***@***.com

Posted: 2005-10-13 0:33:00

java-programmer >> Constructors + Information Hiding In article <434d254a$0$23007$email***@***.com>,
Fabien Bergeret <email***@***.com> wrote:

> Just like any other method : by calling the getters, which can by either
> public or private.
> I consider it quite ugly to call directly the attributes ; it violates
> the encapsulation paradigm.

I don't see this being a major problem...if you ever updated the class
and changed the data model, it would be trivial to update the equals
method since it resides inside the class as well. Its no different than
updating the getter and setter methods.

Accessing fields directly from another class can be a problem, because
then it complicates code maintenance (change a data model in one class
and it breaks another class, e.g.) and if somebody else relies on your
class they have to learn what the internal changes are as well.

--
|\/| /| |2 |<
mehaase(at)gmail(dot)com

Posted: 2005-10-13 3:04:00

java-programmer >> Constructors + Information Hiding Eric Sosman wrote:
> > This is not only useful, as you say, but downright
> > necessary in many cases. Consider writing an equals()
> > method for your VarTest class, one that considers
> > two VarTest objects "equal" if their x and s members
> > are equal. How could equals() make the decision if
> > it didn't have access to the other object's x?

Fabien Bergeret <email***@***.com> wrote:
> Just like any other method : by calling the getters, which can by either
> public or private.

This assumes that the class exposes accessor methods. Accessor methods
are frequently necessary, but good code avoids using them out of habit.
Code that wants to "get" the values of another class's fields is quite
likely to belong in that other class, instead of wherever it currently
resides.

Of course, you could provide private accessors... but that ducks the
question here, and provides absolutely no extra encapsulation.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Posted: 2005-10-13 4:20:00

java-programmer >> Constructors + Information Hiding On 12 Oct 2005 05:48:00 -0700, "Murph" <email***@***.com> wrote
or quoted :

>//I know why this would be a useful constructor,
>// but why is this allowed if the instance variables for
>// vt are private?????

I don't think you understand what private means. See
http://mindprod.com/jgloss/private.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Posted: 2005-10-13 18:50:00

java-programmer >> Constructors + Information Hiding On Wed, 12 Oct 2005 17:01:29 +0200, Fabien Bergeret wrote:

> I consider it quite ugly to call directly the attributes ; it violates
> the encapsulation paradigm.

No, it doesn't. Encapsulation is about hiding implementation details from
users of the class. It never had been, or can be, about hiding
implementation details from the implementation itself.

If there is an accessor available, it should be called, since it might be
overridden by a subclass. However, creating a private accessor is just
silly.

--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Posted: 2005-10-14 14:28:00

java-programmer >> Constructors + Information Hiding In article <434d254a$0$23007$email***@***.com>,
Fabien Bergeret <email***@***.com> wrote:
> > This is not only useful, as you say, but downright
> > necessary in many cases. Consider writing an equals()
> > method for your VarTest class, one that considers
> > two VarTest objects "equal" if their x and s members
> > are equal. How could equals() make the decision if
> > it didn't have access to the other object's x?
> >
> Just like any other method : by calling the getters, which can by either
> public or private.
> I consider it quite ugly to call directly the attributes ; it violates
> the encapsulation paradigm.

Your approach is the object-oriented equivalent of a cargo cult.

--
--Tim Smith

Posted: 2005-10-15 12:06:00

java-programmer >> Constructors + Information Hiding On Fri, 14 Oct 2005 06:27:40 GMT, Tim Smith
<email***@***.com> wrote or quoted :

>
>Your approach is the object-oriented equivalent of a cargo cult.

The principle of information hiding is to hide information from
outside clients if they don't need it, not to hide it from yourself.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.