Informatique

Hello !

J'ai eu récemment un exercice comme ceci (je schématise, je suis via mobile) :

public class A { // code }
public class B extends A { // code }

B truc = new A ();

La question était : est-ce compilable ?

Alors malheureusement je crois m'être trompé, ayant répondu que non.
Mais est-ce que, concrètement, ça arrive en vrai c'est genre de cas ?
Si oui, vous auriez des exemples ? C'est une aberration dans mon esprit de faire ça.

Heu ce n'est clairement pas possible, le type statique ne peut pas être une sous classe du type dynamique

L'inverse cependant, A truc = new B(); est autorisé.

Ce genre de cas*

Parce que la déclaration elle me pique les yeux. Si on a un parent et un enfant, on crée soit l'un soit l'autre. Pas un espèce de bâtard comme ça, non ?

Oups oui j'ai interverti !

Le 13 janvier 2017 à 18:37:07 GrandeGuerre a écrit :
Oups oui j'ai interverti !

La réponse était bien oui alors

Comme exemple:

public class Personne { // code }
public class Adulte extends Personne { // code }

Personne truc = new Adulte ();

Un adulte est une personne mais une personne n'est pas forcément un adulte (première idée bidon qui m'est venue à l'esprit)

Le 13 janvier 2017 à 18:34:47 DaMoY a écrit :
Heu ce n'est clairement pas possible, le type statique ne peut pas être une sous classe du type dynamique

Quel rapport avec typage dynamique et statique ici ?

Le 13 janvier 2017 à 19:09:40 WatchItBurn a écrit :

Le 13 janvier 2017 à 18:34:47 DaMoY a écrit :
Heu ce n'est clairement pas possible, le type statique ne peut pas être une sous classe du type dynamique

Quel rapport avec typage dynamique et statique ici ?

Apparemment j'ai utilisé un vocabulaire que je ne connais pas, oubliez le typage

Un adulte est une personne mais une personne n'est pas forcément un adulte (première idée bidon qui m'est venue à l'esprit)

Ça c'est très clair. Mais la déclaration passe pas dans ma tête.
Soit t'as un Adulte, soit une Personne, tu vas pas instancier ton Adulte en tant que Personne, vu que c'est l'intérêt d'avoir un héritage, non ?

Le 14 janvier 2017 à 11:43:08 GrandeGuerre a écrit :

Un adulte est une personne mais une personne n'est pas forcément un adulte (première idée bidon qui m'est venue à l'esprit)

Ça c'est très clair. Mais la déclaration passe pas dans ma tête.
Soit t'as un Adulte, soit une Personne, tu vas pas instancier ton Adulte en tant que Personne, vu que c'est l'intérêt d'avoir un héritage, non ?

On instancie en tant qu'adulte, mais la variable déclarée est de type Personne
(instance = membre de droite de l'opération cad le type après le new, déclaration = membre de gauche).

L'utilité c'est d'avoir un couplage faible entre ton programme et l'implémentation choisie. En l'occurrence si la suite de ton bout de code fonctionne à minima sur une Personne, on déclarera la variable comme une Personne vu qu'on n'a pas besoin de connaître la spécialisation (Adulte).

Si demain je n'utilise plus l'implémentation Adulte ou la remplace par une autre, le programme reste inchangé.

Ah donc c'est dans un souci de maintenabilité ?

Le 14 janvier 2017 à 12:37:29 GrandeGuerre a écrit :
Ah donc c'est dans un souci de maintenabilité ?

Essentiellement. En informatique il faut toujours privilégier des couplages faibles à des couplages forts.
En revanche si la spécialisation est nécessaire dans ton programme, on va déclarer la variable comme type enfant.

C'est un peu le même principe quand on déclare des map en Java.
Tu peux selon les cas utiliser des HashMap, des LinkedHashMap, des ConcurrentHashMap TreeMap etc.. mais dans tout ton programme tu utiliseras l'interface Map. Ca te permet de changer d'implémentation tout en gardant un programme fonctionnel.

l'intérêt c'est aussi d'avoir des fonctions du style manger(Nourriture plat) et de pouvoir les appeler avec des classes héritantes comme paramètres : manger(BoeufEnDaube) ; manger(SoupeALOignon)

D'accord, je comprends déjà mieux l'intérêt expliqué comme ça. Merci !

En gros, dans ma vision initiale de la chose, on avait ça :

public class Personne {
    // some code
}

public class Etudiant extends Personne {
   // some code
}

Et faire Etudiant eleve1 = new Personne() me semblait incohérent, dans le sens où Etudiant est explicitement une Personne, vu que Etudiant hérite de Personne.
Donc à mon sens, c'était illogique. Je veux dire, oui, un élève est une personne, mais un élève est aussi un étudiant.

Enfin du coup, les méthodes je trouve ça plus explicite, merci beaucoup !