I. Rappel

La redéfinition ou la surcharge suivent des règles précises dans les relations d'héritage.

Dans le cadre de la redéfinition d'une méthode, il faut que la signature de la méthode de la classe fille ait exactement la même signature.

Redéfinition
Sélectionnez
//Classe Mère
public String maMethod(String a,String b){//...}
//Classe fille
public String maMethod(String a,String b){//...}

Dans le cadre de la surcharge d'une méthode, la méthode de la classe fille se distinguera par ses paramètres (leurs nombres et leurs types).

Surcharge
Sélectionnez
//Classe Mère
public String maMethod(String a,String b){//...}
//Classe fille
public String maMethod(String a,Integer c){//...}

II. La covariance

Dans les versions antérieures au JDK 1.5 ces deux règles étaient valables. Depuis la version 1.5 et supérieures ces règles ont légèrement changées.

En effet, il est maintenant possible de modifier le type retour d'une méthode que l'on redéfinit. Dans un premier temps, cette nouvelle possibilité peut paraître quelque peu déstabilisante.

Après réflexion, la covariance des types retour donne la possibilité de s'affranchir de la conversion de type explicite (cast). Le cast, une technique qui introduit des faiblesses dans les programmes et qui met en évidence une faiblesse du typage du langage Java.

Une contrainte existe dans la mise en œuvre de cette technique, il faut que le nouveau type retour soit un sous-type du type déclaré dans la super classe. Cette contrainte reste logique et cohérente. En effet, l'héritage raffine (spécialise) le comportement d'une classe, il est logique que les méthodes redéfinies dans les sous-classes spécialisent aussi les types retours de ses méthodes.

L'utilisation de la covariance ne doit pas être systématique, il faut que celle-ci présente un réel intérêt.

Dans la suite de l'article, nous allons voir plusieurs cas d'utilisation de ce [nouveau] principe qui est maintenant autorisé.

III. Le principe

Nous allons voir ici un exemple simple.

III-A. UML

Image non disponible

III-B. Explications

Dans cet exemple, le type de retour a été spécialisé (MonType -> SousType).

Entre les deux, il y a une relation de sous type. SousType est un sous type de MonType.

Cet exemple n'est peut-être pas très parlant et on ne saisit pas forcement l'intérêt de faire cette modification.

Ne vous inquiétez pas, dans la suite de l'article nous verrons un exemple concret permettant de voir l'intérêt de cette pratique.

IV. La mise œuvre

IV-A. Exemple 1

Ci-dessous nous allons voir un exemple plus parlant avec la méthode clone() définie par l'interface Cloneable. Lorsque l'on souhaite cloner en profondeur un objet on implante cette interface et on redéfinit la méthode clone().

Voila la signature de la méthode :

 
Sélectionnez
public Object clone() throws CloneNotSupportedException;

On notera que cette méthode renvoie un type Object. Si l'objet à cloner est de ce type aucun problème. Par contre, si le l'objet renvoyé n'est pas de ce type, il faudra caster l'objet renvoyer dans le type de l'objet cloné.

 
Sélectionnez
package covariance;

public class ClassCloneable implements Cloneable {

    private String objecName = null; 
    
    /**
     * @return Renvoie objecName.
     */
    public String getObjectName() {
        return objecName;
    }
    /**
     * @param objecName objecName à définir.
     */
    public void setObjectName(String objecName) {
        this.objecName = objecName;
    }
    
    
    /**
     * redéfinition de la méthode clone
     */
     @override
    public Object clone() throws CloneNotSupportedException {
    ClassCloneable newRef = (ClassCloneable) super.clone();

        return newRef;
    }

}

public class Main {
     
    
    public static void main(String[] args) {
       
        ClassCloneable classCloneable = new ClassCloneable();
        classCloneable.setObjectName("nouvel Objet Name");
        try{
            AutreClassCloneable newRef = (AutreClassCloneable)classCloneable.clone();
              
        }catch(Exception err){
            err.printStackTrace();
        }
}

Dans cet exemple, nous voyons que nous devons passer par un 'cast' explicite de l'objet renvoyé par la méthode clone.

Nous sommes obligés de passer par là afin de retomber sur le type d'instance de l'objet cloné.

Cette pratique peut comporter des risques. Dans le cas ci-dessus le code se compilera et s'exécutera correctement.

En revanche, un développeur peu scrupuleux (ou tête en l'air) aurait pu écrire le code suivant :

 
Sélectionnez
package covariance;

public class ClassCloneable implements Cloneable{

    private String objecName = null; 
    
    /**
     * @return Renvoie objecName.
     */
    public String getObjectName() {
        return objecName;
    }
    /**
     * @param objecName objecName à définir.
     */
    public void setObjectName(String objecName) {
        this.objecName = objecName;
    }
        
    /**
     * redéfinition de la méthode clone
     */
     @override
    public Object clone() throws CloneNotSupportedException {
        ClassCloneable newRef = (ClassCloneable) super.clone();

        return newRef;
    }
}

package covariance;

public class AutreClassCloneable implements Cloneable{

    private String objectName = null; 
    
    /**
     * @return Renvoie objectName.
     */
    public String getAutreObjectName() {
        return objectName;
    }
    /**
     * @param objecName objecName à définir.
     */
    public void setAutreObjectName(String objectName) {
        this.objectName = objectName;
    }
    
    
    /**
     * surdéfinition de la méthode clone
     * 
     */
     @override
    public Object clone() throws CloneNotSupportedException {
        ClassCloneable newRef = (ClassCloneable) super.clone();
        return newRef;
    }
    
}
    
public class Main {
    
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
       
        ClassCloneable classCloneable = new ClassCloneable();
        classCloneable.setObjectName("nouvel Objet Name");
        try{
            AutreClassCloneable newRef = (AutreClassCloneable)classCloneable.clone();
              
        }catch(Exception err){
            err.printStackTrace();
        }
}

Dans l'exemple ci-dessus, la compilation se passera sans problème. Le type retour de la méthode est bien un sous-type de la classe Object.

En revanche, au moment de l'exécution, la liaison tardive posera quelques problèmes de 'cast'. Le type renvoyé par la méthode est ClassCloneable et on veut le transtyper en AutreClassCloneable. Il n'y a aucune relation de type entre ces deux classes. L'exécution de ce programme aboutira à une exception de type ClassCastException.

Ce type de situation montre une faiblesse du typage en Java. En effet, le fait de devoir forcer le typage d'un objet peut donner lieu à des problèmes qui interviennent uniquement à l'exécution.

L'utilisation de la covariance sur les types retours nous permet de sécuriser notre code.

Nous allons reprendre l'exemple vu précédemment en introduisant la covariance sur le type retour de la méthode clone.

 
Sélectionnez
package covariance;

public class ClassCloneable implements Cloneable{

    private String objecName = null; 
    
    /**
     * @return Renvoie objecName.
     */
    public String getObjectName() {
        return objecName;
    }
    /**
     * @param objecName objecName à définir.
     */
    public void setObjectName(String objecName) {
        this.objecName = objecName;
    }
    
    
    /**
     * redéfinition de la méthode clone
     * 
     */
     @override
    protected ClassCloneable clone() throws CloneNotSupportedException {
            return (ClassCloneable) super.clone();
    }
}

Dans cette nouvelle implémentation de la classe ClassCloneable, nous pouvons remarquer que le type de retour de la méthode clone() a été spécialisé.

Malgré la modification de la signature cette méthode redéfinit bien la méthode clone de l'interface Cloneable.

IV-B. Exemple 2

Voici un exemple plus général :

IV-B-1. UML

Image non disponible

IV-B-2. Code

 
Sélectionnez
public class A {

    A method(A x){
        return this;
    }
    
}

La classe A ci-dessus, déclare une méthode de type method :A->A.

 
Sélectionnez
public class B extends A {
    
    B method(A x){
        return this;
    }
}

La classe B ci-dessus étend la classe A en redéfinissant la méthode method déclarée.

Le type de cette méthode dans la classe B est method :A->B.

 
Sélectionnez
public class C extends A { 



    C method(A x){

        return this;

    }

}

La classe C ci-dessus étend la classe A en redéfinissant la méthode method déclarée.

Le type de cette méthode dans la classe C est method :A->C.

Dans cet exemple, on voit qu'au fur et à mesure que l'on descend dans l'arbre d'héritage le type retour de la méthode method évolue et se spécialise.

Par conséquent on limite le scope de compatibilité dans les classes filles.

En revanche, on pourra s'affranchir de l'utilisation du cast pour manipuler les types retournés par la méthode method. Dans les deux cas (Classe B et C) la méthode est redéfinie et non surchargée.

Ce code compilera avec le compilateur 1.5.En revanche, des erreurs de type seront générées avec la version 1.4 du compilateur.

V. La covariance : un exemple concret

Nous allons voir dans ce paragraphe un cas d'utilisation concret mettant en évidence l'intérêt de la covariance.

Ci-dessous une interface représentant un panier ainsi que deux implémentations de celle-ci :

 
Sélectionnez
public interface Bag {
   
   
    public void addItem(Item i);
    
    
    
    public Bag addItems(Bag b);
    
}

//Premiere implantation l'interface Bag


public class BooksBag implements Bag {

    public void addItem(Item i) {
        
        //code d'ajout d'un item au panier'
    }

    public void printTitles(){
        //code d'affichage du titre de chaque livre
    }
    
    public Bag addItems(Bag b) {
        
        //Code d'ajout des items au panier
        
        return this;
    }
    
}

//Deuxième implantation du panier.


public class FlowersBag implements Bag{
   
    
    public void addItem(Item i) {
    }
    
    public void compterNombreDePetale(){
        
        //Code permettant de compter le nombre de pétale 
    }

    public Bag addItems(Bag b) {
        
        //Code d'ajout au panier
        
       return this;
    }
}

Dans cette première version, nous n'utilisons pas le principe de covariance.

En effet, la méthode susceptible d'appliquer ce principe est addItems :Bag->Bag. Nous allons mettre en évidence les problèmes sous-jacents dans ce cas.

Ici nous mettons en évidence les problèmes que l'on peut rencontrer :

 
Sélectionnez
public class Main {

    public static void main(String[] args) {
        BooksBag bbAutres = new BooksBag();
        FlowersBag fbAutres = new FlowersBag();    


        BooksBag bb = new BooksBag();(1)
        FlowersBag fb = new FlowersBag();(2)
        
        BooksBag bag = (BooksBag)bb.addItems(bbAutres); (3)
        FlowersBag fbag = (FlowersBag)fb.addItems(fbAutres); (4)

        FlowersBag bag = (FlowersBag)bb.addItems(bbAutres); (5)
        BooksBag fbag = (BooksBag)fb.addItems(fbAutres); (6)
    }
}

Nous commençons par instancier un objet de type BooksBag et un objet de FlowersBag (lignes 1 et 2).

Ensuite, nous appliquons la méthode addItems sur les deux objets instanciés précédemment (ligne 3 et 4).

La remarque qui peut être faite concerne la nécessiter de caster les deux objets dans leur type respectif lors de la récupération de la référence de l'objet modifié. Ce qui n'est pas une bonne chose.

Image personnelle : Il est vrai que nous pourrions être plus abstrait et utiliser le type de l'interface Bag cela nous éviterait d'utiliser le mécanisme de .
En faisant ça, nous perdrions de l'information pour chaque type :
  • la méthode compterNombreDePetale pour la classe FlowersBag ;
  • la méthode printTitles pour la classe BooksBag.

On peut constater aussi qu'il est possible de faire des erreurs de typages (ligne 5 et 6). Ici, la compilation se passera sans problème; par contre, une exception de type ClassCastException sera levée lors de l'exécution.

Maintenant que nous avons mis en évidence ce problème, voyons comment la covariance va nous aider à obtenir un code plus propre, c'est-à-dire que l'on pourra se passer du mécanisme de cast et surtout d'interdire dès la compilation le mélange de type comme vu ci-dessus.

Nous allons maintenant utiliser le mécanisme de covariance afin d'éviter les problèmes vu précédemment :

 
Sélectionnez
public interface Bag {
   
   
    public void addItem(Item i);
    
    public Bag addItems(Bag b);
    
}

//Premiere implantation l'interface Bag

/**
 *
 * @author fabszn
 */
public class BooksBag implements Bag {
    
    
    

    public void addItem(Item i) {
        
        //code d'ajout d'un item au panier
    }

    public void printTitles(){
        //code d'affichage du titre de chaque livre
    }
    
    public BooksBag addItems(Bag b) {
        
        //Code d'ajout des items au panier
        
        return this;
    }
    
}

//Deuxième implantation du panier.


public class FlowersBag implements Bag{
   
    
    public void addItem(Item i) {
    }
    
    public void compterNombreDePetale (){
        
        //Code permettant de compter le nombre de pétale
    }

    public FlowersBag addItems(Bag b) {
        
        //Code d'ajout au panier
        
       return this;
    }
}

Dans cette première version, nous n'utilisons pas le principe de covariance. la méthode impactée est addItems :Bag->Bag.

Selon la sous-classe, cette méthode aura un type retour différent. Les méthodes sont bien redéfinies et non surchargée.

 
Sélectionnez
public class Main {

    public static void main(String[] args) {
        BooksBag bbAutres = new BooksBag();
        FlowersBag fbAutres = new FlowersBag();    


        BooksBag bb = new BooksBag();(1)
        FlowersBag fb = new FlowersBag();(2)
                
        BooksBag bag = bb.addItems(bbAutres); (3)
        FlowersBag fbag = fb.addItems(fbAutres); (4)

        FlowersBag bag = bb.addItems(bbAutres); (5)
        BooksBag fbag = fb.addItems(fbAutres); (6)

        FlowersBag bag1 = (FlowersBag)bb.addItems(bbAutres); (7)
        BooksBag fbag2 = (BooksBag)fb.addItems(fbAutres); (8)
    }
}

Dans le code ci-dessus nous n'avons plus recours au mécanisme de cast. Les erreurs de typage des lignes (5) (6) (7) (8) seront détectées à la compilation et à l'exécution.

Nous avons maintenant un code plus cohérent et plus robuste. Cependant il reste une faille au niveau des arguments. Le principe de la contravariance n'est pas encore implanté dans le langage Java.

Brièvement : ce principe permet de spécialiser les arguments d'une méthode sur le même principe que la covariance.

VI. La covariance et le JDK 5 (et versions ultérieurs)

La covariance n'est pas utilisée dans le cadre du JDK 5 sur les classes historiques.

On utilise bien souvent les interfaces pour laisser des points d'entrer aux développeurs souhaitant étendre les fonctionnalités de l'API.

Par exemple, l'interface List est implémentée de plusieurs façons. Ici, nous retiendrons deux classes l'ArrayList et la LinkedList. Chacune implante une méthode de type clone : Object (méthode issue de l'interface Cloneable).

Dans un contexte autre que celui d'une API (ici le JDK), il aurait été judicieux de remplacer le type retour Object par ArrayList dans un cas et LinkedList dans l'autre. Ceci afin de pouvoir manipuler le bon type sans avoir à caster l'objet retourné.

Hors c'est bien le type Object qui a été utilisé. Lors de l'introduction de la covariance à partir de la version 5 du JDK, les développeurs de Sun ont décidé de ne pas modifier les classes existantes. Ceci sûrement dans un souci de compatibilité ascendante. Néanmoins, ils auraient pu créer de nouvelles classes ou adapter les anciennes comme ils l'ont fait pour les Générics.

VII. Conclusion

Le mécanisme de la covariance apporte une nouvelle perspective au sein du langage Java. Comme les Generics, ce principe donne la possibilité de détecter les erreurs de typage plus tôt durant le développement. Cela permet de diminuer les erreurs au moment de la liaison tardive.

J'espère que cet article vous donnera un bon aperçu du principe de la covariance de type en Java.

VIII. Remerciements

Je tiens à remercier wichtounet, adiGuba, ®om et ricky81 pour leurs conseils et leurs relectures.