Questions about "casting operation" in OOP

Question

When programming, we usually use some type-casting operations.

When the casting happens on the objects "on the same level", it feels ok. But when it happens on the ojects "on the different levels"(mainly between father and son), it feels weird.

Considering this:

Class Son extends Father

WhenSon s = (Son)father;, it's absolutely unreasonable. Because a "Son" is not a "Father" anymore, "Son" may grow up with some new properties "Father" doesn't have, the casting operation makes these properties unknown.

On the other hand, Father f = (Father)son seems reasonable, but according to LSP

"An instance of a derived should be able to replace any instance of its superclass"

A "Son" can do anything his "Father" can, so the casting operation seems useless.

So can i say that these casting operations are agaisnt OO design principle but necessary?

Answer 1

I find questions like these always interesting and it lends itself to some kind of debate I think :)

Here are my thoughts. In class design I would in this case create a class of Person

class Person
{
    public bool IsFather { get; set; } // this variable will change depending on the count of children
    public List<Person> children { get; set; }
}

When I create a derived class, the class should be a specialized person and in the case of Father and Son, I wouldn't create a Father class and a Son class.

Answer 2

Casting objects in OOP is usually the product of either class inheritance or interface inheritance. One has to always remember that class inheritance denotes an "is a" relationship, and interface inheritance denotes a "has a" relationship.

Let's go over to your example: Class Son extends Father doesn't sound like a reasonable abstraction, since every male person is a son, but not all of them will be a father. In fact, the opposite might be more applicable: Class Father extends Son because every father is always someone's son.

On the other hand, we could just ditch this whole abstraction and say that we have, instead, a Class Person that can either be a male or a female, a mother or a father, and so on. Each person will have an attribute containing collection of Person with name Children.

In this abstraction, a Person will only be considered a Father if its gender is male and if Person.Children.Count > 0. This is much simpler than defining a Father class in and by itself.

Answer 3

Neither seem reasonable to me. What seems more plausible:

Son s = (Son)person          //Valid
Father f = (Father)person    //Valid

Answer 4

One you've got a bad example of inherintence.

A better one could be

Class Person 
{
    public void walk();
}
Class Man extends Person
{
    public void shaveBeard();
}

Inheritence is the way to represent a is a relationship eg a Man is a person.

Using the Objects

Either of the 2 lines is ok.

Person p = new Person();
Person m = new Man();

It is fine to call p.walk on both. However to call the shavebeard() method the varible m has to point to a man object. For reasons of type-safety you have to cast it to a man object eg ((Man)m).shaveBeard(); This will fail so it's best to check that it is pointing to an instance of Man eg In Java this would be:

if(m typeof Man)
{
   ((Man)m).shaveBeard(); 
}

Answer 5

what the diffrant between ganarlization and specilization?