Why can't reference to child Class object refer to the parent Class object?

Question

I was explaining OOP to my friend. I was unable to answer this question. (How shameful of me? :( )

I just escaped by saying, since OOP depicts the real world. In rea

Answer 1

The Heap-Stack answer by AaronLS makes perfect technical sense.

References are store on stack while objects are store on heap. We can assign child object to parent type reference because child is type of parent and child object has reference for parent class. While parent is not of type child. Parent object doesn’t have reference to child so child reference can’t point to parent object.

This is the reason why we can cast decimal to int and int to decimal. But we can not cast parent-child both ways. Because parent has no clue about its children's references.

Int i = 5;
Decimal d = 5.5;

d = i;

or 

i = d;

Both are valid. But same is not the case with reference types which are stored on heap.

Answer 2

class "Child" extends "Parent"

"child class object is inherently a parent class object"

 Child aChild = new Child();
 Parent aParent = new Parent();
 aParent = aChild;// is perfectly valid.
 aChild = aParent;// is not valid.

in a code segment like a normal assignment operation, the above is read from right to left. line 3 of the code segment reads - "aChild (a Child class object) is a Parent" (due to inheritence child class objects become superclass objects inherently) thus line no.3 is valid.

whereas in line no.4 it reads, "aParent (a Parent class object) is a child" (inheritence doesn't say that superclass objects will become child class objects. it says the opposite) thus line no.4 is invalid.

Answer 3

Basically, it all comes as way of assignment, as we all are familiar with the data types available in programming languages.

let's take an example of numeric data types and it's assignment.

1. byte can be easily assigned to short without casting.(byte b = 127; short s = b;)

2. short can be easily assigned to int without casting.(short s = 32,767; int i = i;) and so on....

but when we try reverse way, i.e, int to short or short to byte. we get compile time error, then to fix this compile time error, we do type casting as follows below:

int a = 10; byte b = a; //compile time error ; this is because size of int is greater then int, so byte cannot accommodate to have int.

then we do type casting(i.e, value to be assigned gets converted into requested data type and then it gets assigned). i.e, byte b = (byte)a;

Similarly, when it comes to parent class object assigning to child class reference :

child class cannot accommodate to have parent class object, in case if it does also with the help of type casting, will be able to get rid of compile time exception, but will get runtime exception, which is because at run time, child variable will be holding the parent object and there could be possibility where child may request for some features which parent doesn't have.

Answer 4

Exactly because aChild is a superset of aParent's abilities. You can write:

class Fox : Animal

Because each Fox is an Animal. But the other way is not always true (not every Animal is a Fox).

Also it seems that you have your OOP mixed up. This is not a Parent-Child relationship, because there's no composition/trees involved. This is a Ancestor/Descendant inheritance relation.

Inheritance is "type of" not "contains". Hence it's Fox is a type of Animal, in your case it doesn't sound right -- "Child is a type of Parent" ? The naming of classes was the source of confusion ;).

class Animal {}
class Fox : Animal {}
class Fish : Animal {}

Animal a = new Fox(); // ok!
Animal b = new Fish(); // ok!
Fox f = b; // obviously no!

Answer 5

I think, you chose a wrong model for real-life Parents and Children ;) In real life, a Parent is always a Child and a Child can be a Parent.

If you turn it around, it works:

class Child {
  Child[] parents;
}

class Parent : Child {
  Child[] children;
}

A parent is-a child (of his/her own parents) and we can express:

Child aChild = aParent;

because every parent is a child as well, but not

Parent aParent = aChild;

because not all children are parents.

Answer 6

I think you mean:

Child aChild = aParent;

You did not specify that aChild is of type Child.

The reference to a Child type will mean that you can call members on it that may no exist in the Parent. So, if you assign a Parent object to a Child reference, you will be able to call members that do not exist on the Parent.