Considérons un scénario dans lequel nous créons une classe nommée Utilisateur, puis créons une sous-classe qui étend l'utilisateur appelé Employé.
En règle générale, nous créons une instance de Utilisateur avec :

User user = new User();

Ici, User est le type de la variable user, user est la variable qui contient l'instance de la classe et new User() crée une nouvelle instance de User.
En termes simples, l'utilisateur est une instance de User.

Mais que se passe-t-il si la superclasse User doit utiliser des méthodes définies dans sa sous-classe Employee ? Est-ce que cela peut arriver ?
La réponse courte est oui, mais uniquement pour les méthodes remplacées (méthodes qui existent à la fois dans la superclasse et la sous-classe). C'est ce qui permet le polymorphisme.
Puisque la relation d'héritage est la relation "est-un", L'employé est-un utilisateur. ainsi, rien n'empêche User de détenir une référence à une instance de sa sous-classe Employee, tant qu'il s'agit d'un type compatible.

Cela se fait comme suit :

User user = new Employee();

Maintenant, disons que la classe User a deux méthodes :

1. getUserName()
2. getUserSalary().

tandis que la classe Employee a une méthode supplémentaire appelée getEmployeeInformation() et remplace la méthode getUserSalary().

PUIS avec User user = new Employee();:

1. user.getUserName() fonctionnera, tel qu'il est défini dans la classe User.

2. user.getUserSalary() fonctionnera également, mais la sortie proviendra de la méthode getUserSalary() remplacée dans la classe Employee, et non de celle de User . C'est l'essence du polymorphisme.

3. user.getEmployeeInformation() ne fonctionnera pas. Cela générera une erreur de compilation car elle est spécifique à la classe Employee.

Une erreur de compilation se produit lorsque le compilateur détecte des problèmes tels que des erreurs de syntaxe, des incompatibilités de types ou d'autres violations qui empêchent la compilation réussie du code.

Si nous essayons de faire l'inverse et de référencer un objet de sous-classe Employee avec une référence de superclasse User, cela ne fonctionnera pas sans casting manuel ! Cela nécessite un casting explicite, car Utilisateur n'est pas nécessairement un Employé.

Upcasting VS. Downcasting

Après avoir expliqué cela de manière simple, avec un exemple simple, concentrons-nous sur les termes.

"Référence de superclasse à un objet de sous-classe" est généralement appelé upcasting. En termes simples, la conversion ascendante consiste à transtyper un objet enfant en un objet parent, et cela se produit implicitement ( ce qui signifie que le compilateur le gère automatiquement, nous n'avons donc pas besoin d'une syntaxe de conversion spécifique ). C'est comme lorsque nous avons fait User user = new Employee();.

Qu'en est-il du downcasting ?

La diffusion descendante est exactement le contraire de la diffusion ascendante.

Vous vous souvenez quand nous avons dit que la création d'une référence Employé à partir d'une instance d'utilisateur n'était pas valide ? C'est ce qu'on appelle le downcasting, et cela doit être fait explicitement en utilisant la syntaxe de transtypage. Bien que la diffusion ascendante soit très sûre, la la diffusion descendante entraîne des risques. Cela ne veut pas dire qu'il n'est pas utile, mais il doit être utilisé avec prudence.

Je n'entrerai pas dans les détails sur le downcasting puisque cet article se concentre sur le upcasting, mais le point clé est de montrer la principale différence entre le downcasting et le upcasting.

Et c'est fini ! :)