"Infact person class being ancestor has lesser features than Employee, So Employee object must be able to accommodate a person object without any explicit casting. Please elaborate."
No, it's the other way round.
Because Employee is derived from Person, a Person variable can freely contain an Employee (or any other class derived from Person) because all such classes must contain everything that the Person class does. So the system can safely access all the fields, properties, methods, events, and so forth from the Person class without any problems.
But to go the other way invites run time errors! Let's take your example, and turn it round:
Employee emp = new Person();
string des = emp.Designation;
Because
emp
refers to an Employee, Designation is available. But we assigned a Person to the variable - which doesn't have a Designation field, so what is the system supposed to access?
That's why you have to explicitly cast: so that the system can be sure when it accesses derived class features that the class instance actually supports them! The run time cast will fail if the features will not be available because you can't "up-cast" a Person instance to an derived Employee.
"Considering these lines:-
Employee employee1 = new Employee();
Person person1 = employee1;
Console.WriteLine("person1 name:{0}",person1.name);
Person person2 = new Employee();
Employee employee2 = (Employee)person1;
If I write person.Designation in the WriteLine statement it throws a compile time error. But again when I reassign the person1 to Employee object (employee2) the employee2 can be used to access Designation. Now when I assigned the employee1 to person1 what happens to the Designation field. Because in the first WriteLine I could never access Designation using person1(naturally) because it is person. But then what happens to the Designation field which appears back when I assign employee2 with person1(casted). Hope you understand what I intend to say.
Say I had Data in the employee object which I assigned to person1, will that be persistent when I use person1 in the 5th statement. Will this be a good technique in any manner in software development practice?"
If you write
person.Designation
you get a compiler error, because
Designation
is not a field of the
Person
class - and
person
is a variable which can reference any
Person
instance - so you an only access properties, fields, and such like that are part of every
Person
, and not those which are only part of a derived class.
When you cast an instance, you don't change the data, you just change how the system sees the data. Any derived class added information remains a part of the instance.
Think about it with cars.
A Ford is a Car
A Fiesta is a Ford, which is a Car.
A Mondeo is a Ford, which is a Car.
You can say "My Car" and mean a Fiesta, a Mondeo, or a Mercedes A-Class without changing the type of car you drive!
Equally, you can say "My Ford" and mean either a fiesta or a Mondeo, but you can't say "My Ford" and drive away in a Mercedes! :laugh:
The same thing applies to your Person and Employee classes: the variable type that references the instance doesn't change the type of the instance it references, it just controls what you can do with it without casting it to a different type.
It's a very useful practice: it allows you to create a Person class, derive Employee and Customer classes from that, and have a table which can hold both:
List<Person> myList = new List<Person>();
myList.Add(new Employee("Joe Brown"));
myList.Add(new Customer("Mary Shelley"));
The Person class would have the Name and Address - but the Employee would have Salary while the Customer would have DeliveryCost
Make sense?