Discussion :

[TeddySlayer]

Bonjour,

Première question pour moi sur ce forum, j'espère la poser au bon endroit...

J'étudie en ce moment la POO avec Java (mais j'en fais aussi un peu avec du code .NET sur lequel un collègue et moi, tous deux amateurs dans ce domaine, bossons).

Dans du code que nous avons écrit par le passé, nous avons une classe mère, et plusieurs classes filles. La classe mère contient des méthodes, dont le comportement varie en fonction de la classe fille à laquelle appartient l'objet (de fait, nous n'instancions jamais directement d'objet de la classe mère, mais comme nous ignorions le concept de classe abstraite, nous ne l'avions pas formalisé).

Dans notre code, la méthode dans la classe mère peut ressembler à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public ClasseMere MaMethode() {
    if (me instanceOf classeFille1) {
        return ((classeFille1) me).MaMethode();
    } else if (me instaceOf classeFille2) { 
        return ((classeFille2) me).MaMethode();
    } else if [...] 
}

et dans les classes filles nous avons :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public ClasseFille MaMethode() {
    [...]
}

Si je devais écrire cela à la lecture de mes cours de POO, je ferais en sorte d'avoir une classe mère abstraite, cette méthode y étant déclarée mais pas implémentée.
Cette méthode serait ensuite implémentée dans les classes filles.

Ma question étant donc : cela peut il avoir un impact notable en termes de performance ?
Dans le premier cas, on a systématiquement un appel imbriqué de deux méthodes et un ou plusieurs casts.
Dans le second cas, j'imagine que le runtime doit résoudre à l'exécution la classe fille pour appeler la bonne méthode sur l'objet.

[adiGuba]

Salut,


Côté perf ce serait probablement plus performant qu'une succession d'instanceof...

Mais c'est pas vraiment le problème et c'est même une erreur de penser performance à ce niveau là.
Il faut privilégier la lisibilité du code !


Sinon en lieu et place d'une classe abstraite, tu pourrais utiliser directement une interface, bien moins contraignant.

[OButterlin]

Personnellement, je trouve que c'est un non sens de définir le code de la méthode dans la classe mère alors que ce code est dépendant de la classe fille et oblige à faire des cast dans tous les sens...
C'est donc logiquement dans la classe fille qu'elle doit être implémentée.
Rien n'empêche, avec une classe abstraite, de définir la signature de la méthode pour obliger les classes filles de les implémenter.
Du coup, on peut utiliser le type de la classe abstraite pour exécuter la méthode sur des instances des 2 types plutôt que de faire un cast.
On serait un peu dans la logique d'une interface mais bon, s'il y a du code commun, la méthode dans la classe abstraite aurait du sens, un truc comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public abstract ClassMere
{
   protected Integer propriete1;
   protected String propriete2;
 
   public void maMethodeCommune(...)
   {
      un traitement quelconque qui positionne des propriétés par exemple...
   }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public MaClasse1 extends ClassMere
{
   public void maMethodeCommune(...)
   {
      super.maMethodeCommune(...);
 
      des traitements spécifiques à cette classe...
   }
}