Difference between Inheritance and class instances.

I know that you don't have to instantiate the base class to inherit its attributes but what is the difference. When you inherit from a base class does that sub class become part of the base class?

 

you don't have to instantiate the base class to inherit its... err 'attributes' (I think you mean 'members', in mono/.net 'attributes' mean something very specific).

No, the sub class does NOT become part of the base class. The sub class inherits all the members of the base class, but is still distinct from the base class.

You can treat the sub class like it's a base class. This is called polymorphism.

I talk about polymorphism over in this thread I just posted in 15 minutes ago. Maybe check it out, it goes into a lot about inheritance/implementation/etc.

http://forum.unity3d.com/threads/co...or-many-objects-with-different-params.323652/

 

I also just noticed your thread title specifically... and I'd like to approach that question as well.

You seem to be mixing up 'object identity' and 'object type'.

type -
types are the classes/structs/interfaces/etc, in which you define the fields/code that represent an object. This is a blue print of what the object should look like... it's split into 2 parts. The "interface", which is the named methods/functions/properties/etc that can be called on an object of that type... this is often also referred to as the 'shape' of the object. As well as the "implementation", which is the actual code inside the properties/methods that define the actual operations that the class can perform.

A class 'Foo' has a function called 'DoStuff'. DoStuff generates 2 random numbers, sums them together, and returns the result.

Foo is the type.
DoStuff is part of its interface.
The operations of creating random numbers, summing them, and returning the result is the implementation.



object identity -
this is an INSTANCE of an object. All instances have a type, if not multiple types. The type of the object refers to the code behind the object.

See implementation usually has 2 parts to it. The code inside the functions/methods/properties. As well as the fields. Fields are the variable defined at class level (not in a function). These fields represent the 'state' of the object. This state is what is important to us about the object in making it unique. The functions that run on it do the same thing, it's the fields that distinguish the nuance of the results of those function calls.

See, say I have that Foo class, and we attach a field to it as well. And lets adjust the DoStuff function to return the product of that field with a randomly generated value:

Code (csharp):

1.  
2. public class Foo
3. {
4.  
5.     public int Quantity;
6.  
7.     public float DoStuff()
8.     {
9.         return (float)Quantity * Random.value;
10.     }
11.  
12. }
13.  

So, now... the type of an object that is an instance of Foo is of 2 types:

Foo
System.Object

The interface/shape of the object is:

a field of type int named Quantity
a method that returns float named DoStuff with 0 parameters

The implementation behind Foo is:

a field of type int named Quantity
a method that returns float named DoStuff that returns the product of the int Quantity and a randomly generated value


NOTE, the interface and the implementation seem eerily similar... the difference being the interface doesn't actually describe the operations... it's the outward facing, the 'public', bit of the type. If you had a Foo object, it's what you know about it.

For example, that 'Random.value' property does some magic stuff behind the scenes. It performs this algorithm to create a float that is random. You don't know what it is... you don't know the 'implementation' behind it. All you know is the name (value) and the return type (float).

NOW... in our Foo class the fields, our int named Quantity, is what represents the state of a Foo. If we create 2 objects of foo, what distinguishes on Foo from another is this Quantity. 2 Foo objects with Quantity set to 2 will perform the SAME thing when you call DoStuff resulting in the same probabalistic answer (of course the random product creates greater nuance... but lets pretend DoStuff returned the product of Quantity with itself).

It's by changing Quantity that the 2 objects serve the purpose of uniqueness.

THIS is an instance of an object.





Inheritance has NOTHING to do with any of that.

All inheritance has to do with is what fields and methods are defined on a class. Lets say we have another class called 'Bar', that inherits from 'Foo' and adds more functionality:

Code (csharp):

1.  
2. public class Foo
3. {
4.  
5.     public int Quantity;
6.  
7.     public virtual float DoStuff()
8.     {
9.         return Quantity * Random.value;
10.     }
11.  
12. }
13.  
14. public class Bar : Foo
15. {
16.  
17.     public int AnotherQuantity;
18.  
19.     public override float DoStuff()
20.     {
21.         return base.DoStuff() * this.AnotherQuantity;
22.     }
23.  
24. }
25.  

Now an instance of Bar is of 3 types:


System.Object
Foo
Bar


And it has an interface/shape of:


a field of type int named Quantity
a field of type int named AnotherQuantity
a method that returns float named DoStuff


We can treat the Bar object as if it were a Foo object, because it's shaped the same way (this is polymorphism).

But when you call DoStuff a different things happens. The implementation has changed.

It was the product of Quantity with a random value.
Now it's the product of Quantity, a random value, and AnotherQuantity.

THIS is inheritance.[/B]