Is my constructor doing more than I am aware of ?

[Hansjoachim Vonhortenschiem]

I tried to keep the code example small, so sorry for the overall size.

Anyway, it would seem that the instance variable of ParentCon (varP), even though declared as private, is being inherited into the ChildCon object. Else, there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......?

How else could the instance variable exist and be accessible by the ChildCon objects ???

I think that I will be somewhat disturbed to find that there is in fact 2 objects, a ParentCon >and< a ChildCon object in existence as a result of a call to only the ChildCon constructor and that both of these objects are accessible by a single ChildCon reference variable : (

class ParentCon{

private int varP = 6;

   ParentCon(){
    System.out.println("inside ParentCon no-arg const");
   }   

   ParentCon(int var){
    varP = var;
   }

   public int getVarp(){
    return varP;
   }
}

class ChildCon extends ParentCon{

   ChildCon(){
    System.out.println("inside ChildCon no-arg const");
   }

   ChildCon(int val){
    super(val);
   }

// .............................

   public static void main(String args[]){

    ChildCon child1 = new ChildCon();

    System.out.println("child1 varP is "+ child1.getVarp()); // output is 6

    ChildCon child2 = new ChildCon(12);
    
    System.out.println("child2 VarP is "+ child2.getVarp()); // output is 12 

[Jason Koonce]

There is only one object you may have created, but as I understand inheritance, child1 and child2 is indeed an object that is an object of both ChildCon and an object of ParentCon. Basically, you cannot have a child without a parent but you can have a parent without a child(at least in this example, or you have a fur-baby).

Think through what 'extends' actually does. Now, riddle me this Java-man, what does your ParentCon class inherit even though you didn't type extend or any other inheritable statement?

[marc weber]

Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...

The ChildCon object IS-A ParentCon object.

As your output should demonstrate, a ParentCon constructor executes (i.e., creates an object) whenever you create an instance of ChildCon. A ParentCon object is created, and then that object is extended to become a ChildCon.

[Hansjoachim Vonhortenschiem]

marc weber wrote:

Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...

The ChildCon object IS-A ParentCon object.

As your output should demonstrate, a ParentCon constructor executes (i.e., creates an object) whenever you create an instance of ChildCon. A ParentCon object is created, and then that object is extended to become a ChildCon.

Thanks for the reply... but, could someone explain how private members of the superclass are handled in a situation like this ???

Are they initialized as a result of constructor chaining initiated by a subclass constructor?
Are they part of the "end" object, even though declared as private?
If, being private means "not inheritable", then how is it I can access them ?

Basically, I need the play by play of what actually happens behind the scene....

Thanks in advance

[Hansjoachim Vonhortenschiem]

I think I may have the answer.....

Due to constructor chaining, the final object is a superset of all parent class members, including those members declared as private. However, because private members are not inherited, those private members that are included in the superset created by the class that initiated the instance with a call to new(), will be unaccessible by this final object. That is, unless there is also in this superset some inheritable accessor method to retrieve the private members......

Sound about right ?

What would really be nice is if there were some way to see what the final object consisted of, what it could access and what it could not.

For example, if ClassC extends ClassB and ClassB extends ClassA.....

class ClassC extends ClassB{
public int x = 1;
}

class ClassB extends ClassA{
public int y = 2;
private int z = 3;
}

class ClassA{
public int n = 4;
private int m = 5;
}

if you say, ClassC myobj = new ClassC();

what would the picture of the actual object look like ?
what, in other words, would it consist of ?

[Charles Paldino]

Hansjoachim Vonhortenschiem wrote:

marc weber wrote:

Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...

The ChildCon object IS-A ParentCon object.

As your output should demonstrate, a ParentCon constructor executes (i.e., creates an object) whenever you create an instance of ChildCon. A ParentCon object is created, and then that object is extended to become a ChildCon.

Thanks for the reply... but, could someone explain how private members of the superclass are handled in a situation like this ???

Are they initialized as a result of constructor chaining initiated by a subclass constructor?
Are they part of the "end" object, even though declared as private?
If, being private means "not inheritable", then how is it I can access them ?

Basically, I need the play by play of what actually happens behind the scene....

Thanks in advance

A child class must call a constructor of its parent class. If none is called the default constructor will be called automatically.
Private members do not get inherited, but can be accessed through super methods or constructors. That is happening in your example via a constructor.
The variable itself is not a part of the child class, if you attempt to override the getVarp method you will come across compile errors trying to print out the variable.

"ChildCon child1 = new ChildCon(); "

Parent constructor gets called and all parent variables get initialized. THEN child constructor gets called and child variables get initialized.

I think this is the logical process for the code.

Child constructor//ChildCon(){ System.out.println("inside ChildCon no-arg const"); }
----Parent variables initialized //varP = 6
----Parent constructor//ParentCon(){System.out.println("inside ParentCon no-arg const");}
----Child constructor finishes rest of the code
child1.getVarp() //not overridden so it calls the parent's method
--super.getVarp() //Prints out 6

This is the logical process for the other one.
Child constructor //ChildCon(int val){super(val);}
----Parent variables initialized //varP = 6;
----Parent constructor // ParentCon(int var){varP = var;} - Sets var to 12
----Child constructor finishes
child2.getVarp() //not overridden so it calls the parent's method
---super.getVarp() //Prints out 12

[Charles Paldino]

Hansjoachim Vonhortenschiem wrote:I think I may have the answer.....

Due to constructor chaining, the final object is a superset of all parent class members, including those members declared as private. However, because private members are not inherited, those private members that are included in the superset created by the class that initiated the instance with a call to new(), will be unaccessible by this final object. That is, unless there is also in this superset some inheritable accessor method to retrieve the private members......

Sound about right ?

What would really be nice is if there were some way to see what the final object consisted of, what it could access and what it could not.

For example, if ClassC extends ClassB and ClassB extends ClassA.....

class ClassC extends ClassB{
public int x = 1;
}

class ClassB extends ClassA{
public int y = 2;
private int z = 3;
}

class ClassA{
public int n = 4;
private int m = 5;
}

if you say, ClassC myobj = new ClassC();

what would the picture of the actual object look like ?
what, in other words, would it consist of ?

Just use intellisense, or look at an object view in the IDE you are using.

Class A
-public int n = 4;
-private int m = 5;

Class B extends Class A
-public int n = 4; //inherited
--public int y = 2;
--private int z = 3;

Class C extends Class B
public int x = 1;
-public int n = 4; //inherited From B, which inherits it from A
--public int y = 2; //inherited from B

[marc weber]

Hansjoachim Vonhortenschiem wrote:I think I may have the answer.....

Due to constructor chaining, the final object is a superset of all parent class members, including those members declared as private. However, because private members are not inherited, those private members that are included in the superset created by the class that initiated the instance with a call to new(), will be unaccessible by this final object. That is, unless there is also in this superset some inheritable accessor method to retrieve the private members......

Sound about right ? ...

Conceptually, yes, I think that's correct. But the wording can be problematic -- using technically correct definitions of "inherited," "accessible," etc. See this topic.

[Hansjoachim Vonhortenschiem]

Just use intellisense, or look at an object view in the IDE you are using.

if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.

as for and IDE, I use notepad and the command prompt.

but thanks for a reason to use an IDE : )

[Charles Paldino]

Hansjoachim Vonhortenschiem wrote:

Just use intellisense, or look at an object view in the IDE you are using.

if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.

as for and IDE, I use notepad and the command prompt.

but thanks for a reason to use an IDE : )

No.
Intellisense
You might as well go rake yourself over coals, it'd be more productive than notepad + commandprompt

You should grab eclipse or netbeans, there are plenty of tutorials for creating projects on youtube for them.

[Henry Wong]

Hansjoachim Vonhortenschiem wrote:
if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.

Intellisense is the name of the help system for Visual Studios. And Visual Studios is not a common IDE for Java, as Microsoft is more focused on .NET.

Henry

[Charles Paldino]

Henry Wong wrote:

Hansjoachim Vonhortenschiem wrote:
if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.

Intellisense is the name of the help system for Visual Studios. And Visual Studios is not a common IDE for Java, as Microsoft is more focused on .NET.

Henry

Eclipse has practically the same thing, I can't think of the name for it, so I just call it intellisense too.

[Hansjoachim Vonhortenschiem]

Thanks for all the replies.

I followed the link provided by Marc Weber and am now inclined to believe that any object created can and will "possess" all members, including private members of any and all parent classes in its heirarchy tree. Also, those private parent members, though in the possession of the child object, ARE NOT accessible by name from within the child object but ARE accessible if the child object inherits from the parent some form of public accessor method.

So, in my minds eye, I can envision an object consisting of members that are part of that objects blueprint (class), members that are inherited from the parents blueprint(thereby becoming part of the childs blueprint), and those members of the parents blueprint that, though part of the child object, are not part of the childs blueprint. These last members still occupy a space in memory and are accessible via parent provided accessor methods.

The upside is that you can have a unique instance of a parents private instance variable to compliment a child object (assuming you have a way to access it).

The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.

It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......

Assume the parent class has a private instance variable "Rock and Roll" ...... this is a hugh variable !

Now assume the child class has an instance variable "Bruce Springsteen" .... I hope you see where I'm going with this...?

[Jason Koonce]

Hansjoachim Vonhortenschiem wrote:So, in my minds eye, I can envision an object consisting of members that are part of that objects blueprint (class), members that are inherited from the parents blueprint(thereby becoming part of the childs blueprint), and those members of the parents blueprint that, though part of the child object, are not part of the childs blueprint. These last members still occupy a space in memory and are accessible via parent provided accessor methods.

The upside is that you can have a unique instance of a parents private instance variable to compliment a child object (assuming you have a way to access it).

The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.

It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......

You almost have it, the memory allocation is actually part of the Child's requirement. The Child's use of that information is part of the Child, the Child cannot exist without the parents portion. It would otherwise be a programmable immaculate conception, which just like in the real world, we can't make happen. So, the Parent information is part of the child and the memory is not wasted.

My question to you is, have you learned about protected variables and methods? As in public, protected, and private...once you get to that stage you should discover how to indirectly access your parents private variables in a secure way that leads to better programming habits and very little if not no memory being used for no reason. About that stage you should also learn how to release that memory for the garbage collector. I will research the forums and tutorials for a better explanation of this, in the meantime I learned mine in the Deitel 8th edition book, one I highly recommend.

Hope this helps.

[marc weber]

Hansjoachim Vonhortenschiem wrote:... The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.

It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way...

That sounds like more of a design problem than a language problem. With power comes responsibility.

[Jesper de Jong]

One remark (that I've made before on the forums here): Talking about superclasses and subclasses using the words "parent" and "child" is confusing and may make it harder to understand what you're talking about.

The word "inheritance" in object oriented programming has a different meaning than the same word in biology. In object oriented programming, inheritance implies an is a relationship. In other words, an instance of a subclass is an instance of a superclass (with some stuff added to it).

If you call your superclass Parent and your subclass Child, then what you're expressing is: a Child is a Parent. Obviously, in biological terms a child is not a parent, so this confuses things.

Note that we use the word extends to make a subclass inherit from a superclass in Java. That word already indicates what happens: you have a superclass, and then you extend it by adding methods, member variables etc. and then you have a subclass.

A subclass object is just an instance of the superclass object with some things added to it. So when you instantiate the subclass, then it's easy to understand that first the superclass part of the object has to be initialized. That's why a constructor of the superclass needs to be called.

Hansjoachim Vonhortenschiem wrote:The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.

It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......

Assume the parent class has a private instance variable "Rock and Roll" ...... this is a hugh variable !

Now assume the child class has an instance variable "Bruce Springsteen" .... I hope you see where I'm going with this...?

I don't see exactly where you're going with this, but I suspect there's still something about the relationship between superclasses and subclasses that you're missing.

The private variables of the superclass are not there just wasting memory. A subclass object is a complete superclass object, plus the things added to it that the subclass adds. The private parts of the superclass just have to be there, otherwise the object wouldn't be complete. The methods that are defined in the superclass can still use the private member variables that are defined in the superclass part, also if the object is really an instance of a subclass.

[Hansjoachim Vonhortenschiem]

Wow.. .Thanks for the excellent replies guys..... I think the lights have just flickered on in my head....

Not only do I have a much better understanding of what is actually happening, but also a newfound respect for inheritance and what its use implies. I don't mean to create the impression now that inheritance is bad, but I can definitly see how it should be used sparingly if possible.

Well, actually....... if proper cohesion techniques are imployed, then there should not really be any fear of a bloated superclass being extended by trivial subclasses. This, I think, was what I meant by the Rock and Roll & Bruce Springsteen comment I made earlier.... A bloated superclass ( all of rock & roll is HUGH) and a trivial subclass (Bruce is just one element of rock n roll), but any Bruce object will be hugh because it contains all of rock n roll..

If you have many streamlined "specialist" classes, extending some other streamlined specialist superclass then not only do you have more flexability in the type of objects you can create, but you can create them without the concern of wasted memory......

Make sense, or have I missed the boat yet again ?