La vérification à la compilation, c'est bien

Soit un modèle où l'on diffère, sous forme de commandes, des appels à passer à une certaine classe. Par exemple, dans le cas où l'implémentation finale de la classe est distante, on souhaite passer tous les appels dans une seule connexion réseau : on va donc trouver un moyen de « sérialiser » les intentions d'appels, en général sous forme de texte, on les enverra en lot, puis côté serveur la liste sera détricotée, les appels passés, et on retournera la liste des résultats (dans le cas où tout se passe bien).

Pour illustrer le problème, disons que l'interface de la classe distante s'appelle « Toto », avec les méthodes « doSomething(int, int) » et « doSomethingElse(String) ».

On faisait jusqu'ici un appel réseau pour chaque invocation :


Avec le code Java ci-dessous :

final Toto toto = <proxy>; // proxy pour appel distant

toto.doSomething(2, 5); // 1er appel
toto.doSomething(14, 8); // 2e appel
toto.doSomethingElse("Fantastic!"); // 3e appel
toto.doSomething(0, 1); // 4e appel

Après s'être aperçu qu'on pouvait gagner en performances, nous décidons que du point de vue du réseau il n'y aura qu'un appel, qui agrègera les invocations :


Eh bien je ne sais pas pourquoi, mais pour faire ça certains pensent à écrire la chose suivante :

final Commands commands = new Commands(Toto.class);

commands.storeCommand("doSomething", 2, 5); // 1er
commands.storeCommand("doSomething", 14, 8); // 2e
commands.storeCommand("doSomethingElse", "Fantastic!"); // 3e
commands.storeCommand("doSomething", 0, 1); // 4e

CommandUtils.executeCommands(<proxy>, commands);

C'est tout à fait dommage, car on perd l'avantage de la vérification à la compilation : si on se trompe dans une chaîne de caractères qui contient un nom de méthode, ou dans le type des paramètres d'une méthode, on ne s'en apercevra qu'à l'exécution.

En fait il faut s'arranger pour pouvoir coder ainsi :

final Toto toto = FutureUtils.newFuture(Toto.class);

toto.doSomething(2, 5); // 1er appel
toto.doSomething(14, 8); // 2e appel
toto.doSomethingElse("Fantastic!"); // 3e appel
toto.doSomething(0, 1); // 4e appel

FutureUtils.execute(<proxy>);

C'est-à-dire qu'il faut s'appuyer le plus possible sur ce qui compile... déjà.

Un très bon modèle pour penser de cette façon, est EasyMock : ce framework d'aide aux tests permet d'enregistrer les appels à contrôler par du code d'appel ! On a donc la vérification de la syntaxe à la compilation, puis évidemment la vérification de la séquence à l'exécution.