Usage des génériques

Bonjour à tous,

Quotidiennement, je contribue à un projet open-source qui utilise massivement les génériques et je dois me plier à une pratique qui me semble bizarre. J'aurais aimé l'avis de la communauté. Voici un bout de mon code pour illustrer mes propos :

Nous possédons 2 interfaces dans des fichiers différents :

1
2
3

public interface CtStatement {}

public interface CtBlock extends CtStatement {}

Nous possédons maintenant une classe (et son interface) qui va utiliser ces interfaces :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

public interface CtIf extends CtStatement {
  <S extends CtStatement> S getElse();
}

public class CtIfImpl extends CtStatementImpl implements CtIf {
  CtStatement elseStatement;

  @Override
  public <S extends CtStatement> S getElse() {
    return (S) elseStatement; // cast obligatoire
  }
}

Ma question est la suivante :

Pourquoi suis-je obligé de caster mon elseStatement alors qu'il est typé avec un type compatible par rapport à la déclaration du type de la méthode ?

Si vous savez m'éclairer, je suis preneur.

Parce que le type n'est pas compatible, en fait : comme tu précises dans l'implémentation que tu retournes le type S paramétré et non simplement un CtStatement, tu es obligé de rajouter ce cast.

Dans la mesure où j'indique que S doit étendre CtStatement, pourquoi le type serait incompatible ? A noter que quelque chose comme ceci ne fonctionne pas non plus :

1
2
3
4
5

@Override
public <S extends CtStatement> S getElse() {
  CtBlock<?> elseBranch = null;
  return elseBranch; // erreur de compilation alors que CtBlock étend CtStatement
}

Bien vu ça !

Dans la mesure où j'indique que S doit étendre CtStatement, pourquoi le type serait incompatible ? A noter que quelque chose comme ceci ne fonctionne pas non plus :

Le type n'est pas vraiment compatible, parce que tu essaye de mettre une mère dans une fille.

En fait ce que tu décrit ici :

1
2
3
4
5
6
7
8

public class CtIfImpl extends CtStatementImpl implements CtIf {
  CtStatement elseStatement;

  @Override
  public <S extends CtStatement> S getElse() {
    return (S) elseStatement; // cast obligatoire
  }
}

correspond presque à ça (en sachant que toute les classes héritent de Object):

1
2
3
4
5
6
7
8

public class CtIfImpl extends CtStatementImpl implements CtIf {
  Object elseStatement;

  @Override
  public String getElse() {
    return (String) elseStatement; // cast obligatoire
  }
}

Là tu devrais voir pourquoi le cast est obligatoire.

En gros, ta classe fille a potentiellement des attributs que ne possède pas ta classe mère. Lorsque tu essaye de faire rentrer ta classe mère dans la fille, le compilo se demande donc si tu es sur de ce que tu fais car ce n'est pas très naturel. Les attributs en plus que possède la fille ne seront peut-être pas alimentées, d'où le cast pour dire au compilo que tu sais ce que tu fais.

Par contre il n y a pas de problème à faire rentrer la fille dans la mère, car tous les attributs de la mère seront alimentées avec celle de la fille.

Qu'en est-il de mon exemple dans mon message précédent où CtBlock est une classe fille de CtStatement ?

Ok, j'ai compris le souci … Merci à vous 2.