Discussion :

[grunt2000]

Bonjour,

C'est peut être parce que c'est Dimanche, un coup de fatigue ou bien parce que je vieillis, mais je perds mon latin là.

J'ai écrit cette classe:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class StringLocale implements Serializable, Cloneable
{
private Locale m_locale;
private String m_contenu;
 
   @Override public StringLocale clone()
   {
      try
      {
         StringLocale c = (StringLocale)super.clone();
         c.m_locale = (Locale)m_locale.clone();
         return(c);
      }
      catch(CloneNotSupportedException e)
      {
         throw(new DefautLogicielException(e.getMessage(), e));
      }
   }
}

et je m'en accommodais très bien, d'autant qu'elle compilait sans problèmes et montrait sous Eclipse son signe Override...

Jusqu'à ce que je me représente qu'elle n'aurait pas du compiler.
parce que l'interface Cloneable n'est pas générique, et réclame l'implémentation de

Code :

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

public Object clone();

Un peu ébranlé, je me suis dit: tiens, on peut redéfinir le type de retour en implémentant une interface non générique.
Mon monde vacillait déjà quelque peu...

Mais ceci passe aussi:

Code :

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

1
2
3
4
5
6
7
public class Sujet implements Cloneable 
{
   public Sujet clone()
   {
      return(this.clone());
   }
}

Code :

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

1
2
3
4
5
6
7
public class SujetExamen extends Sujet
{
   public SujetExamen clone()
   {
      return(this.clone());
   }
}

Redéfinir le type de retour d'une méthode dont on hérite... je n'avais jamais vu cela avant. Et pourtant, ça passe.

Pourquoi est-ce accepté?

En vous remerciant,

Grunt.

[tchize_]

Ca s'appelle la covariance des type de retour, c'est apparu avec java 5. En gros, une classe qui fait un override d'une méthode du parent peut changer le type de retour, a la seule condition que le nouveau type de retour soit une sous classe du type de retour déclaré dans le parent.

Ainsi, une méthode

public Object x()

peut etre redéfinie dans un enfant

public String x()

[thelvin]

Pourquoi est-ce accepté?

Une manière rapide de voir la réponse à cette question :

quel problème cela pourrait-il possiblement poser ?

SujetExamen étend Sujet. Il implémente donc toutes les méthodes que Sujet implémente, et répond true à instanceof Sujet.
Tout bout de code qui s'attend à recevoir un Sujet et reçoit un SujetExamen "à la place" fonctionnera donc parfaitement. Ceci est la base du polymorphisme.

D'ailleurs même si la méthode disait qu'elle renvoie un Sujet, rien ne l'empêche de renvoyer une instance de SujetExamen. La différence étant qu'elle se serait imposée de donner moins d'information qu'elle n'en a.
Pourquoi faire ?

[grunt2000]

Si tout est normal, ma foi. Moi non plus je ne vois rien à y redire, en fin de compte. C'est même bien pratique.

Il faut croire que je ne m'étais pas essayé à cela depuis Java 1.4, tout simplement.

Merci !
Grunt.

[adiGuba]

Salut,


Pour info tout ceci est indiqué dans la FAQ :

Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?


a++