La résolution de surcharge se produit pendant la compilation, pas au moment de l'exécution.

Ainsi, lorsque vous appelez getWorkDetails(this), this est supposé être un Person (qui est le type statique), et donc appelé le correspondant de surcharge.

Note: L'utilisation de this à l'intérieur de la classe Employee en aurait fait un type Employee. Vous pouvez le vérifier en surcharge work() dans Employee comme ceci.

class Employee extends Person {
    ...

    public void work() {
        getWorkDetails(this); // This should print "This person is an Employee"
    }
}

Solution spécifique au problème

Dans certains langages, les paramètres sont résolus à leur type dynamique, mais pas en java. Le compilateur détermine déjà au moment de la compilation où votre getWorkDetail(this); ira. this est de type Person, donc getWorkDetail(Person e) est appelé. Dans votre cas spécifique, la solution est assez évidente. Comme d'autres l'ont déjà souligné, vous devrez remplacer getWorkDetail() dans la classe Employee.

Résolution des méthodes à leurs types de paramètres dynamiques

Pour résoudre le problème général de la résolution des types de paramètres à l'exécution, en utilisant l'opérateur instanceof doit être évitée, car elle conduit généralement à un code impur.

Si vous avez deux classes différentes, une solution aussi simple que celle indiquée ci-dessus n'est plus possible. Dans ces cas, vous aurez à utiliser le modèle visiteur.

Considérons les classes suivantes:

public interface Animal {
    default void eat(Food food) {
        food.eatenBy(this);
    }

    void eatMeat(Meat meat);

    void eatVegetables(Vegetables vegetables);
}

public class Shark implements Animal {
    public void eatMeat (Meat food) {
        System.out.println("Tasty meat!");
    }

    public void eatVegetables (Vegetables food) {
        System.out.println("Yuck!");
    }
}

public interface Food {
    void eatenBy(Animal animal);
}

public class Meat implements Food {
    public void eatenBy(Animal animal) {
        animal.eatMeat(this);
    }
}

public class Vegetables implements Food {
    public void eatenBy(Animal animal) {
        animal.eatVegetables(this);
    }
}

Que vous pouvez appeler comme ceci:

Animal animal = new Shark();
Food someMeat = new Meat();
Food someVegetables= new Vegetables();
animal.eat(someMeat);        // prints "Tasty meat!"
animal.eat(someVegetables);  // prints "Yuck!"

Suivant le modèle visiteur appelant Animal.eat appellera Food.eatenBy, qui est implémenté à la fois par Meat et Vegetables. Ces classes appelleront la méthode eatMeat ou eatVegetables plus spécifique, qui utilise les types (dynamiques) corrects.

Appeler de préférence

class Foo {
    static void test(int arg) { System.out.println("int"); }
    static void test(float arg) { System.out.println("float"); }
    static void test(Integer arg) { System.out.println("Integer"); }
    static void test(int... arg) { System.out.println("int..."); }

    public static void main(String[] arg) {
        test(6);
    }
}

, La sortie sera int imprimé sur la console. Maintenant, vous commentez la première méthode test() et voyez quelle est la sortie à venir.

C'est la préférence hirarchey dans les types de données primitifs. Maintenant, en venant aux types dérivés, déclarez une classe FooChild comme ceci

class FooChild extends Foo {

}

Et créez deux nouvelles méthodes dans Foo comme

static void testChild(Foo foo) { System.out.println("Foo"); }
static void testChild(FooChild fooChild) { System.out.println("FooChild"); }

Ensuite, dans la méthode principale, essayez d'appeler testChild comme ceci testChild(new FooChild());.

GetWorkDetail (this) ne sait pas quelles sont les sous-classes. appelez getWorkDetail à la place.