Bonsoir,
alors voila, un prof de Programmation Orienté Objet, m'a affirmé quelque
chose ce soir en cour, que je n'ai pas voulu admettre, j'ai donc
testé en rentrant, et ca confirme ce que je pensais, cependant pour être
sur je préfère demander, peut être qu'il y a une astuce qu'il a oublié
de me dire.
Pour faire simple, si une Classe B possede toutes les methodes
(signature), que la Classe A, sans en hériter, et bien on peux placer
une instance de la Classe B dans un tableau de Classe A, car selon lui,
la Class B, serait un sous-type de la Classe A, exemple.
public ClassA
{
public void maMethode(int nb){}
}
public ClassB
{
public void maMethode(int nb){}
}
public ClassC
{
public static void main(String[] args)
{
ClasseA[] leTableauDeA = new ClasseA[2];
leTableauDeA[0] = new ClasseA();
leTableauDeA[1] = new ClasseB(); <= Ca plante à la compile comme je
le pensait, mais le prof dis que ca marche .....
}
}
Donc voila, si quelqu'un à des idées sur ce qu'il a voulu dire.
PS : je n'ai pas confondu avec les notions d'héritage, si d'interface en
Java, qui permettrais en modifiant le code de faire fonctionner, j'ai
bien fait répéter, et il me la écris au tableau, c'est bien cela qu'il
affirme, une Classe B pour être un sous-type de la Classe A, sans pour
autant etre une sous-classe.
Ca ne dépend pas du JDK, ce comportement est lié aux specs du langage, pas au JDK.
Mouais, mais un comportement qui fait a coup sur une erreur à l'exec, ca serait pas mal qu'elle soit gérée a la compil, d'où ma question un peu neuneute :o) Et c'est quel paragraphe dans la jls qui "permet" ça ?
Dans la seconde édition du Gosling (1996), c'est décrit à la section 10.10 (Array Store Exception).
Effectivement, ça serait mieux si c'était détecté à la compil (à ma connaissance, c'est le seul cas où on peut avoir une erreur de type au runtime alors qu'il n'y a pas de cast explicite dans le source). On pourrait le faire en rendant les types A[] et B[] incompatibles (pas d'assignement possible entre eux, sauf en passant par Object) mais les designers de Java ont probablement jugé que c'était trop restrictif et qu'il valait mieux relaxer le typage statique dans ce cas et vérifier les types à l'exécution.
Bruno.
Xavier.
Ca ne dépend pas du JDK, ce comportement est lié aux specs du langage,
pas au JDK.
Mouais, mais un comportement qui fait a coup sur une erreur à l'exec, ca
serait pas mal qu'elle soit gérée a la compil, d'où ma question un peu
neuneute :o)
Et c'est quel paragraphe dans la jls qui "permet" ça ?
Dans la seconde édition du Gosling (1996), c'est décrit à la section 10.10
(Array Store Exception).
Effectivement, ça serait mieux si c'était détecté à la compil (à ma
connaissance, c'est le seul cas où on peut avoir une erreur de type au
runtime alors qu'il n'y a pas de cast explicite dans le source). On pourrait
le faire en rendant les types A[] et B[] incompatibles (pas d'assignement
possible entre eux, sauf en passant par Object) mais les designers de Java
ont probablement jugé que c'était trop restrictif et qu'il valait mieux
relaxer le typage statique dans ce cas et vérifier les types à l'exécution.
Ca ne dépend pas du JDK, ce comportement est lié aux specs du langage, pas au JDK.
Mouais, mais un comportement qui fait a coup sur une erreur à l'exec, ca serait pas mal qu'elle soit gérée a la compil, d'où ma question un peu neuneute :o) Et c'est quel paragraphe dans la jls qui "permet" ça ?
Dans la seconde édition du Gosling (1996), c'est décrit à la section 10.10 (Array Store Exception).
Effectivement, ça serait mieux si c'était détecté à la compil (à ma connaissance, c'est le seul cas où on peut avoir une erreur de type au runtime alors qu'il n'y a pas de cast explicite dans le source). On pourrait le faire en rendant les types A[] et B[] incompatibles (pas d'assignement possible entre eux, sauf en passant par Object) mais les designers de Java ont probablement jugé que c'était trop restrictif et qu'il valait mieux relaxer le typage statique dans ce cas et vérifier les types à l'exécution.
