Mais pourquoi n’y a-t-il pas de multidispatch en Java ?

« Voilà une conception dont je peux être fier ! Elle n’est pas forcément extraordinaire, mais elle va simplifier drastiquement le code qui a été écrit. Bon, mettons la en pratique… Mais !… Que se passe-t-il ?… Noooon ! Pas de multidispatch, pas de multiméthode. Je vais devoir mettre du class cast et du instanceof partout. Java, je te hais ! »

Dans cet article, je vous propose de découvrir ce qu’il s’est passé.

Partons d’un exemple.

Vous souhaitez bénéficier d’une classe comportant des méthodes permettant de convertir des objets quelconques en chaîne de caractères indiquant la classe de l’objet et sa valeur. Afin d’éviter l’immonde instanceof et son fidèle compagnon class cast, vous allez naturellement vous tourner vers la surcharge de méthode.

public class Stringfier {

    public static String stringFrom(Object o) {
        return "Object: " + o.toString();
    }

    public static String stringFrom(String o) {
        return "String: " + o;
    }

    public static String stringFrom(Integer o) {
        return "Integer: " + o.toString();
    }

}

Jusque là, rien d’anormal. Vous faites quelques tests simples, qui passent bien

int anInteger = 1;
assertThat(Stringfier.stringFrom(anInteger)).isEqualTo("Integer: 1");

String aString = "string";
assertThat(Stringfier.stringFrom(aString)).isEqualTo("String: string");

Sauf que vous décidez de corser l’affaire : sans changer leur initialisation, vous décidez de typer toutes vos variables en java.lang.Object (la généricité ultime ;-) ). Et là, ça se passe différemment

Object anIntegerAsObject = anInteger;
assertThat(Stringfier.stringFrom(anIntegerAsObject)).isEqualTo("Object: 1");    // expected: "Integer: 1"

Object aStringAsObject = aString;
assertThat(Stringfier.stringFrom(aStringAsObject)).isEqualTo("Object: string"); // expected: "String: string"

wat?!

Java est apparemment partisan du moindre effort, mais il faut savoir que la détermination de la méthode à appeler se fait à la compilation (ce qui n’est plus tout à fait vrai depuis Java 7 avec l’instruction invokedynamic, voir plus loin). Et dans le cadre d’une surcharge de méthode, Java n’ira jamais voir au-delà de la façon dont vous aurez typé vos variables pour savoir quelle méthode appeler. Pour être plus précis, lorsque vous utilisez des variables dont le type est aussi spécialisé que possible, Java n’aura aucun problème pour appeler la méthode voulue. Mais si vous vous amusez à utiliser des types plus globaux pour déclarer vos variables, à la compilation, Java n’a pas la possibilité de deviner ce que vous avez mis dedans.

En fait, il existe un unique moyen de déterminer la bonne méthode à appeler même si vous utilisez des variables typées java.lang.Object : c’est de le faire au runtime.

Multidispatch

Le multidispatch est apparu initialement dans Common Lisp via le Common Lisp Object System (CLOS) et est repris dans Clojure. Souvent représenté sous forme de multiméthode, le multidispatch permet de déclarer des méthodes de même nom mais dont le type des paramètres change. Rien de nouveau jusque là. Java représente cette capacité par la surcharge. Cependant, dans le Common Lisp, l’appel de la bonne méthode se base sur le type intrinsèque des instances passées en paramètre. En Java, ce n’est pas le cas, car Java se base sur le type déclaré.

La souplesse qu’offre du coup le multidispatch fait que nous pouvons très bien ne pas limiter le multidispatch au type des paramètres. Il est même possible d’élargir le concept et baser la vérification sur l’ordre d’apparition des paramètres, leur quantité, leur valeur, etc. Pour le dernier cas, on parle de predicate dispatch. Enfin, le multidispatch est applicable sur des méthodes ayant plus d’un paramètre.

Multidispatch en Java

Afin de forcer Java à choisir la bonne méthode, il faut passer par la réflexion :

1. on récupère l’appel à la méthode,
2. on effectue une recherche de la bonne méthode, en utilisant notamment des critères sur les paramètres,
3. on transmet l’appel à la méthode trouvée.

Tel qu’il est présenté ici, le multidispatch est une forme d’édition dynamique des liens (dynamic linkage) . C’est-à-dire que la méthode à appeler n’est pas déterminée à la compilation mais plutôt au runtime.

Approche simple

L’implémentation ci-dessous permet d’émuler le multidispatch en Java sur la base du type intrinsèque exact des paramètres. C’est-à-dire que si nous déclarons une implémentation de méthode qui prend en paramètre un java.util.List, elle ne fonctionnera pas avec des paramètres de type java.util.ArrayList.

public abstract class MultiMethod {

    protected Object invoke(String methodName, Object... params) {
        Class[] paramTypes = new Class[params.length];
        for (int i = 0; i < params.length; i++) {
            paramTypes[i] = params[i].getClass();
        }

        try {
            Method method = getClass().getDeclaredMethod(methodName, paramTypes);
            return method.invoke(this, params);
        } catch (Exception e) {
            throw new UnsupportedOperationException(e);
        }
    }

}

Voici l’exemple que nous avons vu précédemment, mais cette fois en utilisant la classe MultiMethod.

public class Stringifier extends MultiMethod {
    public String stringFrom(Object o) {
        return (String) super.invoke("_stringFrom", o);
    }

    private String _stringFrom(String s) {
        return "String: " + s;
    }

    private String _stringFrom(Integer i) {
        return "Integer: " + i;
    }
}

Ici, les cas couverts par le code présenté sont simples. Nous supposons qu’à chaque type correspond un traitement spécifique. Comme précisé précédemment, ce code ne permet cependant pas de gérer l’héritage. Par exemple, j’ai une méthode qui traite spécifiquement les java.lang.Number. Si je passe un java.lang.Integer, la méthode ne sera pas appelée. Autre cas non géré : nous traduisons le cas où aucune méthode n’est trouvée par l’envoi d’une exception. Il pourraît être intéressant d’appeler dans ce cas une méthode qui récupère toutes les tentatives d’appel qui ont échoué. Une sorte de method_missing comme en Ruby.

Des approches plus complètes

• jmultimethod (http://logand.com/blog/jmultimethod/index.html#sec-3) est une implémentation plus complète en Java de ce que nous avons vu précédemment.
• Nice programming language (http://nice.sourceforge.net/) est un langage de programmation basé sur Java et proposant une syntaxe pour gérer le multidispatch.
• Clojure (http://clojure.org/), dialecte de Lisp, est un langage plus connu, il propose une implémentation des multiméthodes.

Autres approches

La principale approche concurrente au multidispatch est le pattern matching. Le pattern matching est une sorte de switch-case beaucoup plus souple et plus puissant. Cette structure peut être utilisée pour réaliser des comparaisons sur des valeurs scalaires ou non, sur des types ou même sur de vrais motifs lorsque le langage intègre la notion de type algébrique. La principale différence avec les multiméthodes, c’est que dans le cadre du pattern matching, le code est colocalisé dans la même fonction. Alors que pour les multiméthodes, le code est réparti entre plusieurs méthodes généralement du même nom, mais avec des signatures différentes.

Scala, Haskell et OCaml sont des exemples de langage proposant le pattern matching. Ci-dessous, nous avons réécrit l’exemple précédant en Scala en se basant sur le pattern matching.

def stringFrom(value: Any): String = value match {
  case s:String => "String: " + s
  case i:Int => "Integer: " + i
  case o => "Object: " + o
}

Une autre approche consiste à utiliser le pattern Visiteur pour émuler le double dispatch. Le double dispatch est une version simplifiée du multidispatch, puisqu’il est limité à deux objets. Le principe de l’émulation consiste à mettre en place dans toutes les classes visitables une méthode accept qui prend en paramètre un visiteur et l’utilise en passant this en paramètre. Ainsi, même si nous exécutons le dispatch avec une variable déclarée avec une classe parente, le type véritable de l’instance qu’elle contient se dévoile par this. Du côté visiteur, il faut définir une méthode visit par type de classe de l’arborescence des visitables. Voici un exemple :

public interface ShapeVisitor {
    String visit(Shape shape);
    String visit(Circle circle);
    String visit(Square square);
}

public class Shape {
    public String accept(ShapeVisitor visitor) {
        return visitor.visit(this);
    }
}

public class Circle extends Shape {
    public String accept(ShapeVisitor visitor) {
        return visitor.visit(this);
    }
}

public class Square extends Shape {
    public String accept(ShapeVisitor visitor) {
        return visitor.visit(this);
    }
}

public class GetClassShapeVisitor implements ShapeVisitor {
    public String visit(Shape shape) {
        return "Shape: " + shape.getClass().getSimpleName();
    }

    public String visit(Circle circle) {
        return "Circle: " + circle.getClass().getSimpleName();
    }

    public String visit(Square square) {
        return "Square: " + square.getClass().getSimpleName();
    }
}

Voici un exemple d’utilisation :

GetClassShapeVisitor visitor = new GetClassShapeVisitor();

Shape shape = new Shape();
assertThat(shape.accept(visitor)).isEqualTo("Shape: Shape");

Shape circle = new Circle();
assertThat(circle.accept(visitor)).isEqualTo("Circle: Circle");

Shape square = new Square();
assertThat(square.accept(visitor)).isEqualTo("Square: Square");

Nous voyons très bien que vous ne pourrez utiliser le double dispatch que sur du code que vous pouvez modifier pour pouvoir ajouter la méthode accept. Avec des classes comme String, Object, Integer ou provenant de bibliothèques extérieures, nous sommes bloqués. Autre point, la solution est plus lourde à implémenter.

Enfin, le multidispatch n’est pas sans rappeler le fonctionnement de l’instruction de la JVM invokedynamic (JSR292). L’instruction invokedynamic est générée à la compilation avec en paramètre le nom de la méthode à appeler, le type de sortie et les types d’entrée, ainsi qu’un lien vers une méthode appelée bootstrap. Le bootstrap est utilisé par invokedynamic au runtime pour récupérer un lien vers une méthode cible. Il est possible de réaliser le multidispatch sur la base de l’instruction invokedynamic (voir invokedynamic newbie question). Néanmoins, cette instruction n’est pas directement disponible depuis le langage Java.