Cet article se place dans la continuité de l’article précédent: Il y a peut être une option pour continuer ¡¿.
Avant de présenter de nouvelles techniques – les promises / deferred / future – nous commencerons par transposer les techniques vues précédement en javascript. En poussant le bouchon un peu plus loin, nous verrons les limites de Maurice et comment, à force de promesses, des alternatives se proposent. A l’issu de cet article TL;TR, les fonctions de rappel ne devraient plus avoir de secret pour vous!

Preambule: Javascript ça function-ne pas mal!

L’une des richesses de Javascript par rapport à d’autres langages (comme « Java ») est que la function est un objet de première classe: Une fonction est un objet et il est possible de l’affecter à une variable.

var add = function(a,b) { return a + b; }

Il est même possible de définir des fonctions qui renvoient d’autres fonctions, on parle alors de fonction d’ordre supérieur:

var adder = function(a) {
  return function(b) {
    return add(a, b);
  }
};

var add7 = adder(7);
assert(add7(0) === 7);
assert(add2(35) === 42);

Enfin, on peux même définir des fonctions qui prennent d’autres fonctions en paramètres et renvoient des fonctions:

var curry = function(func, a) {
  return function(b) {
    return func(a,b);
  }
}

var add7 = curry(add, 7);
assert(add7(0) === 7);
assert(add7(35) === 42);

Un autre exemple, que l’on rencontre sans doute plus fréquement, en jquery :

$("#login").on('click', function (event) {
    $("#login-pane").show();
});

Une fonction de rappel est invoquée lorsqu’un clic est détecté sur l’élément login; elle affiche alors l’élément login-pane.

Notes:

• J’invite le lecteur à lire l’excellent article: Les fonctions et les fonctions d’ordres supérieur si ce n’est pas déjà fait.
• Fonction d’ordre supérieur
• Curryfication

Les techniques vu précédemment

Première technique :

Ajouter une fonction supplémentaire comme paramètre lors de l’appel d’une méthode. Cette fonction pourra alors être appellée avec le résultat du calcul lorsque celui sera disponible.

Reprenons le code Java de notre première technique et transposons le en un équivalent javascript:

public class QuizService {
 ...
 public void create(String quizContent, Effect<Quiz> effect) {
 Quiz quiz = quizFactory.create(nextId(), quizContent);
 effect.e(quiz);
 }
}

devient:

QuizService.prototype.create = function(quizContent, callback)
{
  var factory = this.quizFactory;
  var quiz = factory.create(this.nextId(), quizContent);
  callback(quiz);
}

La transposition est relativement claire. Illustrons cela par un exemple d’appel:

quizService.create("<question4aChampion>...", function(quiz) {
  displayQuiz(quiz);
});

Une fois le quiz créé, il est passé en paramètre à notre fonction qui se contente de demander son affichage. Comme les arguments sont identiques cela peux même se réduire à (n’oubliez pas qu’une fonction est un objet de première classe):

quizService.create("<question4aChampion>...", displayQuiz);

Passons rapidement à la deuxième technique:

Deuxième technique :

La fonction de rappel est définie comme prenant un résultat dont le type peut varier en fonction du déroulement du calcul...

public class QuizService {
  public void create(String quizContent,
                     Effect<Either<Quiz,Failure>> effect) {
    if(quizIsUnique(quizContent)) {
      Quiz quiz = quizFactory.create(nextId(), quizContent);
      Either<Quiz,Failure> left = Eithers.left(quiz);
      effect.e(left);
    }
    else {
      // Failure is a Pojo but could
      // also be an UniqueConstraintException
      Failure failure = new Failure(Code.NonUniqueQuiz);
      Either<Quiz,Failure> right = Eithers.right(failure);
      effect.e(right);
    }
  }
}

Là, les choses vont commencer à se simplifier:

QuizService.prototype.create = function(quizContent, callback)
{
  if(this.quizIsUnique(quizContent)) {
    var factory = this.quizFactory;
    var quiz = factory.create(this.nextId(), quizContent);
    callback(null, quiz);
    // or callback.apply(null, [null, quiz]);
  }
  else {
    var failure = new Failure(Code.NonUniqueQuiz);
    callback(failure);
    // or callback.apply(null, [failure]);
  }
}

$(".button").click(function() {
 var buttonId = $(this).attr("id");
 console.log( "Button clicked: " + buttonId);
});

Qu'avons-nous fait? Eh bien notre fonction de rappel peut prendre deux paramètres: le premier, s'il est non nul (voir aussi Falsy values in javascript) désigne une erreur, tandis que le second désigne le résultat en cas de succès.
Par convention, on place généralement l'erreur comme premier paramètre.

Voyons alors le code appellant:

quizService("...", function(err, quiz) {
  if(err) {
    displayErrorFeedback(err);
  }
  else {
    displyFlashFeedback(quiz);
  }
})

Allez hop, on enchaine avec la troisième technique:

Troisième technique :

La fonction de rappel est définie comme prenant un résultat dont le contenu est optionnel

Avant:

public class QuizService {
  public void save(Quiz quiz, Effect<Option> effect) {
    try {
      repository.save(quiz);
      effect.e(Options.none());
    }
    catch(RepositoryException re) {
      Failure failure = new Failure(re);
      effect.e(Options.some(failure));
    }
  }
}

Après:

QuizService.prototype.save = function(quiz, callback) {
  try {
    this.repository.save(quiz);
    callback();
  }
  catch(e) {
    callback(e);
  }
}

Bon... en pratique on verra (ou ecrira) très rarement du code comme ça! mais plutôt:

QuizService.prototype.save = function(quiz, callback) {
  this.repository.save(quiz, function(err,res) {
    callback(err);
  });
}

ou même beaucoup plus simplement:

QuizService.prototype.save = function(quiz, callback) {
  this.repository.save(quiz, callback);
}

Illustrons cela par un exemple d'utilisation:

quizService.save(quiz, function(err) {
  if(typeof err !== "undefined") {
    displayErrorFeedback(err);
  }
  else {
    displayFlashFeedback(Code.QuizSaved);
  }
}
});

Que pouvons-nous constater? Qu'il est possible d'invoquer la même fonction javascript avec ou sans un nombre variable de paramètres. C'est à la charge de la fonction invoquée de vérifier le nombre de paramètres passés, éventuellement leurs types, afin de choisir le comportement qu'elle doit adopter.
Dans notre cas, on vérifie l'existence d'un paramètre qui, le cas échéant, sera référencé par la variable err. En l'absence de paramètre, cette variable sera considérée comme indéfinie.

Pourquoi ne pas utiliser if(err) puisque undefined est évaluée comme false (rappel: Falsy values in javascript)? Uniquement au cas où l'instance décrivant l'erreur serait évaluée à false (se serait maladroit mais bon... sait-on jamais). Les tatillons pourraient dire: "mais pourquoi tout à l'heure on ne s'est pas préoccupé de ça?" hummm... et bien tout simplement parce qu'il faut y aller petit à petit et donner différentes techniques au fur et à mesure.

Passons très vite sur la quatrième technique:

Quatrième technique :

La fonction de rappel est définie comme une fonction ne prenant aucun paramètre, elle est invoquée pour signaler que l'action désirée est effectuée

QuizService.prototype.save = function(quiz, onceSaved) {
  this.repository.save(quiz, function(err,res) {
    onceSaved();
  });
}

Et pourquoi parler de Javascript maintenant?

Eh bien parce qu'il devient difficile de ne pas voir que son utilisation devient de plus en plus présente avec des interfaces utilisateur de plus en plus riches. Il suffit de voir l'approche RIA et son nombre croissant de framework: Backbone.js, AngularJS, Ember.js, KnockoutJS, ... et même Batman.js! (voir Todo MVC pour la comparaison d'une TODO list réalisée avec les différents frameworks).
Et malgré ce que peuvent en dire certains, sa présence côté serveur - popularisée par la plateforme NodeJs -a de quoi nous interpeller. D'ailleurs une grande partie du succès de NodeJs réside dans son approche non bloquante, et toute son API est tournée autour des techniques que nous venons de voir: des appels asynchrones auxquels on passe des fonctions de rappel.

Reveille le Numérobis qui sommeille en toi!

Voyons à quoi ressemblerait une application prenant en compte à chaque appel cette notion de fonction de rappel:

checkUniqueness(data, function(err) {
  if(err)
    displayError(err);
  else
    createQuiz(data, function(err, quiz) {
      if(err)
        displayError(err);
      else
        saveQuiz(quiz, function(err, quizId) {
          if(err)
            displayError(err);
          else
            lookupQuiz(quizId, function(err, quiz) {
              if(err)
                displayError(err);
              else
                sendQuiz(quiz)
            })
        })
    })
})

Mouais... c'est un bien bel escalier qui se dessine; certains parlnte même de pyramide funeste:

As we all know, asynchronous I/O leads to callback API’s, which lead to nested lambdas, which lead to... the pyramid of doom

Why coroutines won't work on the web

Le code devient difficile à lire, à comprendre et par conséquent à maintenir et à faire évoluer!

Pour la petite histoire, c'est justement en arrivant à ce constat en écrivant le code implémentant les différents motifs vus dans AMQP 101 - Part 1 que j'ai cherché une alternative plus élégante pour écrire la même fonctionalité. Il me fallait trouver une manière plus lisible d'écrire et donc de comprendre les exemples, tout ça pour toi cher lecteur! (On vous bichone bien non?)

Des promesses, des promesses et encore des promesses

Que ce cache sous ce titre? Et bien une nouvelle technique: les Promises

Voyons tout d'abord le résultat auquel on souhaite arriver en reprenant l'example précédent:

checkUniqueness(data)
  .then(displayError, function(data) {
    return createQuiz(data);
  })
  .then(displayError, function(quiz) {
    return saveQuiz(quiz);
  })
  .then(displayError, function(quizId) {
    return lookupQuiz(quizId);
  })
  .then(displayError, sendQuiz);

que l'on peut alléger en (souvenez-vous: une fonction est un objet de première classe - hummm je radote là?):

checkUniqueness(data)
  .then(displayError, createQuiz)
  .then(displayError, saveQuiz)
  .then(displayError, lookupQuiz)
  .then(displayError, sendQuiz);

On retrouve alors notre enchainement d'appels, mais cette fois chaque appel est lié au précédent via la méthode then. Cette methode enregistre alors deux fonctions de rappel: une pour le traitement d'erreur et une pour le traitement du résultat.
Ces fonctions de rappel seront alors invoquées lorsque l'appel précédent sera terminé en fonction de son échec ou de son résultat. L'erreur ou le résultat est alors automatiquement transmis en paramètre aux fonctions de rappel enregistrées.

Il s'agit là du principe des Promises en gros: tu m'invoques, je te renvoie un accusé de reception sur lequel tu peux t'enregistrer, quand j'aurai fini mon traitement je te promets que je te passe son résultat.

L'interêt est alors de pouvoir enchainer ces promises et ainsi de décrire tout l'enchainement du traitement qui devra être effectué à mesure que les résultats passent d'une étape à l'autre. Le découplage entre les étapes apparait clairement, et il devient plus facile d'insérer ou de modifier des étapes.

Afin de faire apparaitre les promises, le code précédent pourrait être réécrit de la manière suivante (il s'agit strictement du même code, la seule différence est de faire apparaitre explicitement les variables intermédiaires au lieu de chainer les appels directement):

var promise0 = checkUniqueness(data);
var promise1 = promise0.then(displayError, function(data) {
                  return createQuiz(data);
                });
var promise2 = promise1.then(displayError, function(quiz) {
                  return saveQuiz(quiz);
                });
var promise3 = promise2.then(displayError, function(quizId) {
                  return lookupQuiz(quizId);
                });
promise3.then(displayError, sendQuiz);

A quoi pourrait ressembler une implémentation très simpliste (voir q pour une implémentation plus complète et beaucoup plus robuste):

var Promise = function () {
  this.resolved = false;
  this.callbacks = [];
};

Promise.prototype.resolve = function(error, data) {
	this.data = data;
  this.error = error;
	this.callbacks.forEach(function(cb) {
    if(error)
      cb[0](error);
    else
      cb[1](data);
  });
	this.callbacks = [];
	this.resolved = true;
}

Promise.prototype.then = function(errCallback, okCallback) {
	if(this.resolved) {
        if(this.error)
          errCallback(this.error);
        else
          okCallback(this.data);
    }
    else {
    	this.callbacks.push([errCallback, okCallback]);
	}
}

Ok... et comment on transforme nos méthodes précédentes pour intégrer cela? Et bien cela nécessite d'adapter légèrement nos API afin qu'elles intègrent directement les Promises:

var checkUniqueness = function(data) {
  var promise = new Promise();
  db.checkUniqueness(function(error) {
    promise.resolve(error, data);
  });
  return promise;
}

var createQuiz = function(data) {
  var promise = new Promise();
  service.createQuiz(data, function(error, quiz) {
    promise.resolve(error, quiz);
  });
  return promise;
}

...

Biensûr tout cela a encore plus d'interêt lorsque les appels db.checkUniqueness(...) et service.createQuiz(...) sont asynchrones:
Les deux méthodes précédentes sont invoquées et avant même que le résultat ne soit disponible la promise correspondante est retournée afin de continuer à définir le traitement à effectuer. La chaine de traitement est définie en même temps que la base de données ou que notre service travaille.

Quelques explications?

checkUniqueness est invoquée avec les données à vérifier data. Une promise est instancié spécialement pour l'occasion afin d'être notifiée lorsque le traitement sera terminé. La vérification d'unicité est alors déléguée à la base de donnée (fallait bien trouver un responsable!) et en attendant son verdict, la promiseest retournée telle quelle.
Il est alors possible d'enregistrer plusieurs callback dessus en utilisant la méthode then(cbErr,cbOut) (exemple: .then(displayError, function() { return createQuiz(data); })).
Les callback ainsi enregistrés seront alors notifiés dès que le résultat sera disponible, c'est à dire lorsque la méthode promise.resolve(err,out) est invoquée avec le résultat du traitement.

Le public averti pourra s'appercevoir qu'une promise est - elle-même - basée sur le mécanisme de callback et se place elle-même en fonction de rappel sur le traitement effectué.

L'exemple précédent nous a montré comment transformer des appels imbriqués en des déclarations séquentielles.
Exploitons désormais quelques possibilités offertes par les librairies autour de ces promises (nous baserons notre discours sur la librairie q).

Voyons comment nous pouvons étendre les mêmes techniques à des traitements effectués en parallèle, et plus particulièrement ceux nécessitant des points de "synchronisation": une fois que mes sous-tâches sont terminées alors seulement la suite de mon traitement peut continuer.

Par exemple si nous souhaitons générer tout un recueil de quiz:

Commençons par définir une fonction utilitaire de création de quiz, regroupant ce que nous avons pu voir jusqu'à présent. La fonction retourne une promise sur la création du quiz:

function generateQuiz(errorHandler) {
  var promise =
        generateData()
          .then(errorHandler, checkUniqueness)
          .then(errorHandler, createQuiz)
          .then(errorHandler, saveQuiz);
  return promise;
}

Une fonction utilitaire qui génèrera nbQuiz en invoquant la fonction précédente:

function generateBook(nbQuiz, errorHandler) {
  var i,
      promises = [];
  for(i=0; i < nbQuiz; i++) {
    var promise = generateQuiz(errorHandler);
    promises.push(promise);
  }

  return return Q.all(promises);
}

Le retour de notre méthode generateBook est une promise. Les fonctions de rappels qui seront "branchées" dessus seront alors invoquées lorsque les nbQuiz questionnaires auront été générés, créés et enregistrés.

generateBook(25, errorHandler)
  .then(errorHandler, generateTableOfContent)
  .then(errorHandler, sendToFrance3)
  ...;

En continuant de creuser, on peux trouver beaucoup d'autres techniques. On s'apperçoit que cela ouvre énormément de possibilités quand à la gestion de tâches asynchrones, éventuellement concurrentes, et ce de manière lisible.

Qui est concerné?

Suis-je concerné? Je pensais que le Javascript était executé par un seul fil d'execution et là on me parle de traitement asynchrone ?

One of the fundamental features of client-side JavaScript is that it is single-threaded: a browser will never run two event handlers at the same time, and it will never trigger a timer while an event handler is running, for example. Concurrent updates to application state or to the document are simply not possible, and client-side programmers do not need to think about, or even understand, concurrent programming.

Javascript The Definitive Guide 6th Ed - 22.4 WebWorkers

Et en quoi cela nous concerne-t-il si l'on développe sur le navigateur?

Eh bien parce qu'il n'est pas toujours question de traitement effectué sur le navigateur, mais il peut aussi s'agir d'interaction avec des systèmes tierces comme une requête AJAX:

A corollary is that client-side JavaScript functions must not run too long: otherwise they will tie up the event loop and the web browser will become unresponsive to user input. This is the reason that Ajax APIs are always asynchronous and the reason that client-side JavaScript cannot have a simple, synchronous load() or require() function for loading JavaScript libraries.

Javascript The Definitive Guide 6th Ed - 22.4 WebWorkers

Everything except network operations happens in a single thread

So, You Want to Be a Front-End Engineer?

Les bibliothèques JQuery et Dojo fournissent d'ailleurs des API selon le modèle des promises appellé chez eux deferred (Dojo ~ Deferreds et JQuery ~ Deferreds).

De plus, comme l'auront noté les petits malins, HTML5 définit la notion des WebWorkers qui permet d'effectuer des traitements en dehors du fil d'execution Javascript de la page. Il est donc tout à fait possible d'effectuer des traitements asynchrones même sur un navigateur en les déléguant à des WebWorkers (Nous reviendrons sans doute sur eux dans un prochain article).

Quand à la plateforme NodeJs, et bien, elle intègre par construction la nature asynchrone de chaque appel IO (Input/Output). Les spécifications sur lesquelles s'appuient la plateforme prévoit même une API unifiée et standard pour les promises (CommonJS ~ Promises/A pour lequel q est compatible).

Et pour ceux qui jamais au grand jamais ne toucheront à du javascript!?

Et bien, tout d'abord, vous avez tort de ne pas vous y interesser. Ensuite, ces notions non-bloquantes deviennent de plus en plus présentes et l'on retrouve tous ces concepts dans les langages intégrant les notions de process/acteur (erlang et scala dont l'excellente librairie akka) et du coup dans les frameworks comme Play! ou GPars.

Webographie

Une très belle présentation:

• Futures et Promesses en Scala 2.10 (en)

• Fonction d'ordre supérieur
• Curryfication

• kriskowal / q : A tool for making and composing asynchronous promises in JavaScript

• "How to Survive Asynchronous Programming in JavaScript" on InfoQ

• CommonJS ~ Promises/A
• Dojo ~ Deferreds
• JQuery ~ Deferreds
• Understanding JQuery.Deferred and Promise
• Node.js and Asynchronous Programming with Promises

• Todo MVC

• Akka
• Play!

Livres

• JavaScript: The Definitive Guide
• JavaScript: The Good Parts

• leurs approches “convention over configuration”
• leur relation étroite avec HTTP (verbes, content-negociation)

Rui, toujours partisan de l’artisanat logiciel, expose fièrement un T-shirt “SC with superpowers”, et nous accueille par une présentation des prochains évènements du groupe ALT.NET France et un appel au sponsoring des évènements (le mois prochain, présentations de projets OSS sous forme de lightning talks), avant de laisser la parole à Mathias.

Service Stack

La première présentation, par Mathias, tourne autour de Service Stack, qui est une alternative aux solutions Microsoft ASP.NET MVC, Web API pour créer des applications REST et des services. Il s’agit d’un ensemble de briques composables, incluant par exemple :

• une gestion de la sérialisation / désérialisation
• un client Redis (stockage sous forme de paires clé / valeur en open-source)
• une gestion de cache (dans Redis ou Memcached)
• un mapping objet-relationnel (ORMLite)

L’ensemble de cette stack est compatible avec MONO (et peut même tourner sur un iPhone, avec tout l’intérêt que ça comporte mais qu’on n’a pas encore trouvé). L’architecture est très orientée DTO (message), par opposition à une vision traditionnelle plutôt orientée RPC (procédure). Service Stack est toujours activement développé et remporte un succès croissant. Mathias nous indique en particulier que le format Swagger, qui est une forme de description de contrat pour les services REST, sera bientôt intégré dans Service Stack.

Mathias enchaine avec des démos, avec un exemple de service REST dont on parcourt le code coté serveur. En particulier, on y observe une IoC incorporée et l’absence de configuration. Une grande partie du fonctionnement se fait par respect des conventions, mais celles-ci ne sont pas toujours documentées et il peut être un peu dur de s’y retrouver car le non-respect de la convention ne génère aucun message d’erreur, juste une appli qui ne tient pas compte de ce que l’on a fait… Le conseil de Mathias : partir de l’exemple qui fonctionne bien et adapter à ses besoins, plutôt qu’essayer de partir “from scratch” et lutter dans le vide. Nous observons la mise en place de l’injection d’un repository, l’ajout de routes (très simple).

Coté client, les appels sont également très clairs. Dans le cas d’un client et serveur tous les deux en .NET, les DTO sont simplement partagés, ce qui permet de retrouver directement ses objets et de gérer sérialisation / désérialisation automatiquement. Au fur et à mesure des démos, on remarque :

• la gestion de credentials (plusieurs providers d’authentification sont utilisables très simplement),
• la notion de validateur de demandes de mises à jour des ressources,
• la gestion de rôles…

Les services peuvent être “découverts” par l’intermédiaire d’une page web listant toutes les ressources exposées dans chacun des formats proposés : XML, JSON, CSV, JSV, SOAP (1.1 et 1.2). Visiblement, il n’est pas si facile que ça de sortir du standard, et faire du SOAP consommable depuis un autre client (par exemple WCF) nécessite tout de suite beaucoup plus de configuration.

Service Stack peut aussi être utilisé pour générer du contenu HTML en mode MVC (bien que ce ne soit pas son but premier), et intègre le moteur Razor (qui a été open-sourcé par Microsoft depuis déjà quelque temps). La même URL peut donc être utilisée pour demander différentes représentations d’une même ressource, dont une au format HTML à destination d’utilisateurs humains (parce qu’il n’y a pas que des machines dans la vie !). De la même manière qu’auparavant, la convention doit être respectée : la vue Razor doit porter le même nom que la classe de la ressource.

Pour finir, Mathias insiste sur la quantité de plug-ins disponibles autour de Service Stack. S’en suit une séance de questions / réponses autour des thèmes convention / configuration, REST, Hypermédia, API traversantes…

Nancy FX

La deuxième présentation, menée par Rui, traite de NancyFX, qu’il nous vend immédiatement comme “Vachement mieux que Service Stack” !

Rui retrace l’évolution de l’offre web Microsoft ASP.NET dans le passé :

• ASP.NET Web Forms : on ne peut rien faire (en termes de personnalisation), “Pas assez de contrôle”
• ASP.NET MVC : on peut tout faire (IoC etc…) mais très verbeux dans la personnalisation, beaucoup de configuration et ça n’est pas facile, “Le cout du contrôle est trop élevé”

Il résume ses envies de développeurs par :

• Composition
• Injection
• Convention over configuration
• Comportement par défaut intéressant,
• Autant que possible, une connexion automatique (“auto-wire”) des différents éléments
• Open-source (si possible)

Ses besoins sont simples : “Maitrise, Puissance, Simplicité”. Exigeant, tout de même…

Et bien la réponse qu’il nous propose, c’est Nancy : “un framework léger, low-ceremony, pour construire des services basés sur HTTP, en .NET et Mono”. Nancy est directement affilié à Sinatra, un framework web créé par la communauté Ruby. La religion de Nancy est la suppression de la “friction” que l’on peut trouver lorsqu’on met en œuvre un framework. Les concepteurs de Nancy cherchent à nous proposer un “super-duper-happy-path” pour construire nos applications : tout est “sympa” à utiliser.

Nancy peut se résumer dans la formule “DSL over HTTP + IoC”, c’est à dire un langage spécialisé au dessus d’HTTP, avec un mécanisme d’inversion de contrôle inclus. Et en plus, ça tourne partout (puisque ça s’appuie sur OWIN) !

S’ensuivent quelques démos, une installation à base NuGet avec zéro configuration, pas de bootstrap à mettre en place. Bien que la démo reste simple, tout est très lisible et mis en œuvre facilement. De par son inspiration provenant du monde Ruby, l’utilisation des dynamic est intensive. Tout est très isolé et décomposé.

Au fur et à mesure des démos, nous découvrons en action :

• le moteur de vues intégré par défaut “SuperSimpleViewEngine”, qui permet d’écrire des vues dans une syntaxe rappelant très fortement celle de Razor,
• le conteneur d’injection de dépendance par défaut, TinyIoc, qui permet de faire les opérations classiques d’Ioc, qui fonctionne par défaut avec une injection par constructeur et une résolution par convention de nommage,
• un exemple de développement en TDD,
• la mise en place d’un bootstraper personnalisé,
• le système de diagnostique incorporé au framework et un aperçu de l’espace de gestion du site incorporé (consultation des traces, etc.).

De ces démos et des questions correspondantes, j’ai retenu quelques citations qui m’on semblées pertinentes : “Un framework web, au fond, ce n’est que de l’infrastructure” et “Non, ce n’est pas de la magie noire” !

Conclusion

Ces deux présentations m’ont permis de voir en action des framework dont j’avais déjà entendu parler mais que je n’avais pas eu l’occasion (ni pris le temps) de tester. De mon point de vue, ces projets nous montrent que c’est à la croisée des systèmes, en s’inspirant de ce qui se fait de mieux ailleurs (ici Ruby et le monde des langages dynamiques) que l’on trouve les solutions intéressantes et innovantes. Le public de développeurs .NET (pour la grande majorité) a semblé très inspiré, et chacun est rentré chez soi avec plus d’idées qu’il n’en avait en arrivant… preuve que cette soirée était une belle réussite !

Pour ceux qui souhaitent d’autres informations et qui passent du temps dans les transports, pleins de références de podcasts, choisissez votre programme préféré :

• Service Stack : Dot Net Rocks 843 avec Demis Bellot, The Tablet Show 60 avec John Sonmez, Hanselminutes 300 (Demis Bellot) et 348 (John Sonmez).
• Nancy : Herding Code 123 et 156 (Andreas Håkansson and Steven Robbins), Hanselminutes 270 (Andreas Håkansson) et 351 (Richard Cirerol)

@pirrmann

C’est quoi une fonction ?

Ce qu’on entend par fonction varie selon les langages de programmation mais la définition que je vais donner ici est suffisante pour les propos de l’article. Une fonction est une transformation qui produit une valeur à partir d’un ensemble de paramètres, les arguments de la fonction.
Les choses seront plus claires avec des exemples. Si nous notons par x un nombre entier quelconque. x peut donc prendre comme valeur 0, 1, 2 etc. nous pouvons définir la fonction f comme suit :

Ne vous laissez pas impressionner par la notation. f est le petit nom donné à la fonction, la lettre x à gauche de la flèche désigne l’argument de la fonction et à droite se trouve sa définition. En donnant une valeur spécifique au paramètre, par exemple 1 nous obtenons :

Si x vaut 3 la valeur retournée par la fonction est :

Au vu de ces valeurs il est aisé de comprendre que cette fonction double la valeur qu’on lui passe en paramètre. Renommons la fonction afin de mieux exprimer cette intention :

Le langage Scala est utilisé dans la suite pour illustrer nos propos. Et la fonction double est codée en Scala comme suit :

def double(number: Int) = 2 * number

Dans le code ci-dessus le mot clé def permet de définir une fonction. Il est suivi du nom de la fonction. J’ai choisi, à la place du paramètre x, un nom plus parlant : number. L’annotation Int (pour Integer) spécifie au compilateur que le paramètre number est un entier. Le reste du code est une traduction parfaite du pseudo code.

Les sorties suivantes de la console interactive (REPL) de Scala permettent de tester notre fonction :

$ scala
scala> def double(number: Int) = 2 * number
double: (number: Int)Int
scala> double(3)
res0: Int = 6
scala> double(1)
res1: Int = 2

Une fonction peut avoir plusieurs arguments par exemple la fonction faisant la somme de deux nombres entiers prend deux arguments. Soient x et y les deux entiers dont nous souhaitons faire la somme, la fonction add est définie comme suit :

Cette définition se traduit aisément en Scala de la façon suivante :

def add(x:Int, y:Int) = x + y

Le test de la fonction donne :

$ scala
scala> def add(x:Int, y:Int) = x + y
add: (x: Int, y: Int)Int
scala> add(1, 2)
res0: Int = 3

Et si nous souhaitions définir une fonction qui incrémente un entier nous pouvons réutiliser la fonction add. En effet incrémenter un entier revient à lui ajouter 1 :

def increment(number: Int) = add(number, 1)

En action cela donne:

scala> def increment(number: Int) = add(number, 1)
increment: (number: Int)Int
scala> increment(3)
res1: Int = 4
scala> increment(10)
res2: Int = 11

Note : Une propriété importante de chacune des fonctions que nous avons vues jusque là est le fait que la valeur de retour est entièrement déterminée par les arguments de la fonction.

Munis de ces informations passions aux fonctions d’ordre supérieur.

Les fonctions d’ordre supérieur

Une fonction d’ordre supérieur est une fonction qui a au moins l’une des deux caractéristiques suivantes :

• prend en paramètre une ou plusieurs fonctions
• sa valeur de retour est une fonction

Les fonctions d’ordre supérieur aident à l’expressivité du code en mettant l’attention sur la tâche à accomplir plutôt que sur la façon de l’accomplir : le code dévient ainsi plus déclaratif. Cela devient plus clair avec un exemple. Considérons la classe Person ci-dessous :

public class Person {
 private final String name;
 private final String email;
 private final int age;

 public Person(String name, String email, int age) {
  this.name = name;
  this.email = email;
  this.age = age;
 }

 public String getName() {
  return name;
 }

 public String getEmail() {
  return email;
 }

 public int getAge() {
  return age;
 }
}

Supposons que vous disposez d’une liste d’objets de type Person sur laquelle vous souhaitez faire différentes opérations : transformation, filtrage etc. Commençons par la transformation de la liste.

Transformation des éléments d’une collection

Voici la liste initiale :

List<Person> persons = Arrays.asList(//
				new Person("Toto", "toto@email.com", 23), //
				new Person("John Doe", "john.doe@email.com", 34), //
				new Person("Mad Max", "mad.max@crazymail.com", 20), //
				new Person("Jane Doe", "jane@email.com", 17));

La première transformation qui nous intéresse est l’extraction des adresses email à partir de la liste des personnes. C’est ce que fait la méthode extractEmails :

public static List<String> extractEmails(List<Person> persons) {
	List<String> emails = new ArrayList<String>();

	for (Person person : persons) {
		emails.add(person.getEmail());
	}

	return emails;
}

Testons ce que cela donne :

System.out.println("Emails = " + extractEmails(persons));

Sortie de la console :

Emails = [toto@email.com, john.doe@email.com, mad.max@crazymail.com, jane@email.com]

On obtient une liste ayant la même taille que la liste des personnes mais ne contenant que les adresses email. Le code de la méthode extractEmails recèle quelques défauts dont la “dilution” de l’intention de la méthode dans du code verbeux.

Avant de voir comment résoudre ces défauts implémentons une autre fonctionnalité : extraire les noms à partir de la liste des personnes :

public static List<String> extractNames(List<Person> persons) {
	List<String> names = new ArrayList<String>();

	for (Person person : persons) {
		names.add(person.getName());
	}

	return names;
}

Cette méthode fait ressortir un autre défaut de notre code : la duplication. Les deux méthodes ne diffèrent véritablement que par la transformation effectuée à chaque itération sur l’élément de la liste initiale. Cette transformation peut être matérialisée par une fonction f qui prend comme argument un objet de type Person et retourne son nom ou son adresse email. Ainsi l’implémentation de l’une ou l’autre de nos fonctions se résume comme suit : « applique la fonction f à chaque élément de la liste initiale et renvoie-moi la liste correspondante. »

Nous pouvons schématiser cette phrase de la façon suivante, avec à gauche la liste initiale et à droite la liste obtenue suite à la transformation :

Cela correspond exactement à ce que fait la fonction map. La figure ci-dessous donne le fonctionnement de la méthode map présente sur la classe List de Scala.

Comme mentionné sur la figure la fonction map prend en paramètre une fonction, celle que nous souhaitons appliquer à chaque élément de la liste initiale. Dans notre cas la fonction a comme type Person => String.

Nous allons maintenant réimplémenter nos deux méthodes en utilisant la méthode map disponible dans l’API des listes Scala.

Les fonctions extractEmails et extractNames revisitées

Définition de la classe Person :

case class Person(name: String, email: String, age: Int)

Nous définissons d’abord la fonction qui extrait une adresse email à partir d’une instance de Person :

def extractEmail(person: Person) = person.email

Puis nous passons cette fonction à la méthode map de la liste afin de récupérer la liste des adresses email.

def extractEmails(persons: List[Person]): List[String] = persons.map(extractEmail)

Sur le même principe voici la définition de la fonction extractNames :

def extractName(person: Person) = person.name
def extractNames(persons: List[Person]): List[String] = persons.map(extractName)

def extractNames(persons: List[Person]): List[String] = persons.map(p => p.name)
def extractEmails(persons: List[Person]): List[String] = persons.map(p => p.email)

Qu’avons-nous gagné par rapport à avant ? Le code est plus expressif en éliminant le bruit et en mettant l’accent sur l’intention du code : « mapper chaque élément de la liste sur son application à la fonction que nous passons à la méthode map« .
Les fonctions d’ordre supérieur rendent pratique une autre opération courante sur les collections : le filtrage.

Filtrer une collection

Nous disposons d’une liste de nombres entiers allant de 1 à 15 et nous souhaitons filtrer cette liste en éliminant tous les éléments qui ne sont pas des multiples de 3. Ce genre d’opération est résolu en programmation fonctionnelle avec la fonction d’ordre supérieur filter. Elle prend en arguments une liste et un prédicat, une fonction qui retourne « vrai » ou « faux ». Dans notre exemple le prédicat retourne “vrai” si son argument est un multiple de 3 et « faux » dans le cas contraire. Scala étant un langage orienté-objet filter est une méthode de List.
Voici la définition du prédicat :

scala> def isMultipleOfThree(number: Int) = number % 3 == 0
isMultipleOfThree: (number: Int)Boolean
scala> isMultipleOfThree(2)
res0: Boolean = false
scala> isMultipleOfThree(6)
res1: Boolean = true

Et la liste de nombres :

scala> val numbers = List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)
numbers: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)

Le filtrage s’effectue simplement en passant la fonction isMultipleOfThree à la méthode filter de la liste de nombres :

scala> val multiplesOfThree = numbers.filter(isMultipleOfThree)
multiplesOfThree: List[Int] = List(3, 6, 9, 12, 15)

Ceci peut être réécrit en remplaçant isMultipleOfThree par une fonction anonyme :

scala> numbers.filter(number => number % 3 == 0)
res2: List[Int] = List(3, 6, 9, 12, 15)

Nous allons maintenant combiner filter et map.

Combiner filter et map

Nous souhaitons obtenir la somme des doubles des multiples de 3 compris entre 1 et 15. Cela correspond à une opération de filtrage (suppression des nombres non multiples de 3) suivie d’une transformation des éléments (doublement des éléments des éléments restants) et enfin une opération de réduction (la sommation). On y arrive aisément avec le code suivant :

scala> val numbers = List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)
numbers: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)
scala> numbers.filter(number => number % 3 == 0).map(number => number * 2).sum
res7: Int = 90

Il nous reste une dernière fonction d’ordre supérieur à découvrir avant de conclure cet article : la fonction fold.

La fonction fold, le couteau suisse

La fonction fold est un véritable couteau suisse. Elle réduit les éléments d’une liste en une valeur. Cette fonction existe en deux versions : l’une (foldLeft) parcourt la liste de la gauche vers la droite et l’autre de la droite vers la gauche (foldRight). Nous allons plutôt utiliser la première dont voici la signature :

def foldLeft[B](z: B)(f: (B, A) ⇒ B): B

C’est une fonction curryfiée. Elle prend une valeur initiale de type B, désignée par z et une fonction f prenant deux arguments de types A (le type des éléments de la liste) et B. Pour chaque élément de la liste la fonction f est invoquée. f est invoquée avec la valeur initiale z fournie à la méthode foldLeft. Puis la valeur résultante est passée avec le deuxième élément de la liste à la fonction f. Ce processus continue avec tous les éléments de la liste. Pensez à lire cet article si vous souhaitez en savoir davantage. Place à l’action !

Afin de comprendre comment fonctionne foldLeft nous allons résoudre trois petits problèmes. Le premier problème consiste à faire la somme des éléments d’une liste d’entiers.
La valeur initiale dans le cas de la somme est 0 (l’élément neutre de l’addition) et la fonction f additionne ces deux paramètres. Voici ce que cela donne dans le REPL :

scala> val nums = List(1, 2, 3, 4)
nums: List[Int] = List(1, 2, 3, 4)
scala> val sum = nums.foldLeft(0)((acc, num) => acc + num)
sum: Int = 10
scala> val nums2 = List(1, 3, 5, 7)
nums2: List[Int] = List(1, 3, 5, 7)
scala> val sum2 = nums2.foldLeft(0)((acc, num) => acc + num)
sum2: Int = 16

Simple non ?! Ne nous arrêtons pas en si bon chemin continuons sur le deuxième problème : faire le produit des éléments d’une liste. La valeur initiale passée à foldLeft dans ce cas est l’élément neutre de la multiplication à savoir 1. Quant à la fonction à passer foldLeft elle fait le produit de ces deux paramètres.

scala> val nums = List(1, 2, 3, 4)
nums: List[Int] = List(1, 2, 3, 4)
scala> val prod = nums.foldLeft(1)((acc, num) => acc * num)
prod: Int = 24
scala> val nums2 = List(1, 3, 5, 7)
nums2: List[Int] = List(1, 3, 5, 7)
scala> val prod2 = nums2.foldLeft(1)((acc, num) => acc * num)
prod2: Int = 105

So far so good! Maintenant résolvons le dernier exercice pour la route. Il s’agit de construire à partir d’une liste d’entiers une map dont les clés sont les éléments pairs de la liste et les valeurs leurs doubles. Voyons un exemple afin de clarifier les choses :

List(7, 2, 10, 8, 6) -> Map(2 -> 4, 10 -> 20, 6 -> 12)

La valeur initiale est une map vide. La fonction passée à foldLeft prend une map et un entier. Si l’entier est pair son double est mappé sur sa valeur. La fonction retourne la map résultante.

scala> val nums = List(1, 2, 3, 4)
nums: List[Int] = List(1, 2, 3, 4)

scala> val evenDoubled = nums.foldLeft(Map[Int, Int]()) { (acc, num) =>
| if (num % 2 == 0) acc + ((num, 2 * num)) else acc
| }
evenDoubled: scala.collection.immutable.Map[Int,Int] = Map(2 -> 4, 4 -> 

Pour conclure

Nous arrivons à la fin de cette introduction aux fonctions d’ordre supérieur. Elles sont particulièrement adaptées aux traitements sur des collections. Mais leur usage va au-delà des collections. Consultez la liste de références ci-dessous pour aller loin.

Références

• Higher Order functions
• Learn you a Haskell for Great Good !
• Pure, functional Javascript

Alors vous ouvrez votre IDE, vous le configurez aux petits oignons et vous commencez à comm…

Minute !

Tous les commentaires ne sont pas nés égaux. En fait le code source de la plupart des applications est encombré de commentaires parfaitement inutiles et il en découle que des commentaires en quantité ne signifient pas que le code est correctement documenté.

Il existe de nombreux types de commentaires néfastes, mais il y en a deux qui en constituent la grande majorité : les radoteurs et les menteurs.

Les premiers se reconnaissent immédiatement :

Souvent générés automatiquement, ces commentaires n’apportent strictement aucune information. A bannir, donc.

Les menteurs quant à eux posent un autre problème :

Rien ne vous choque ? Il a y contradiction entre le code et le commentaire. Écrire des commentaires a un prix, ils doivent être maintenus pour rester cohérents avec le code. C’est pour cette raison qu’on ne doit commenter du code que lorsque c’est indispensable à sa compréhension.

Informer sans commenter

Le point clé pour ne pas avoir à écrire des commentaires qui risquent de devenir obsolètes, c’est d’écrire du code qui s’explique tout seul. Cela veut dire exprimer clairement ses intentions au travers du code.

Le choix des noms dans le code est primordial car ils portent la plus grande part de l’information sur l’intention du développeur.

Les noms de classes, de fonctions et de variables doivent avoir du sens, être clairs et sans ambiguïté. Idéalement, on cherchera à avoir des noms prononçables et concis.

Voici deux fonctions qui font exactement la même chose, néanmoins la seconde est compréhensible sans qu’il n’y ait besoin d’explications supplémentaires.

Il est également recommandé de maintenir une certaine cohérence pour les noms au travers de l’application, ce qui renforce la compréhension. On veillera par exemple à utiliser les verbes (de type “fetch”, “get”, “delete”, “update”) de la même façon dans tout le code.

Améliorer la structure

Pour rendre plus explicite un programme, on peut jouer sur une autre dimension et faire émerger des noms dans le code par refactoring : extraction d’expression dans des variables locales, extraction de code dans de nouvelles méthodes ou de nouvelles classes sont autant d’occasions de mettre un nom explicite sur une portion de code.

Cette technique permet d’expliquer simplement des expressions régulières (souvent cryptiques pour qui n’a pas l’habitude) ou des expressions booléennes complexes :

Ce travail est applicable à toutes les échelles de l’application et peut donc être appliqué sur des portions très locales, dans une perspective d’amélioration d’un existant. Faire l’effort de donner un nom à un concept oblige à réfléchir à sa cohérence et sa bonne formalisation : lorsqu’il est difficile de trouver un nom, c’est en général signe d’un problème dans la conception (le cas est criant pour les classes et permet de détecter rapidement les violations du Single Responsibility Principle)

Un peu d’amour quand même

Si minimiser la part des commentaires dans son application est avisé, il ne s’agit pas pour autant de les éradiquer. Ils restent un outil indispensable au développeur.

Ils permettent de fournir de l’information “hors code” (prévenir qu’un test unitaire est très long à exécuter), placer des marqueurs à destination du développeur (TODO, FIXME, à utiliser avec parcimonie) et parfois de clarifier un peu plus l’intention, comme par exemple de dire quel algorithme a été utilisé.

Par ailleurs, dès lors que l’on travaille sur une API publique, une bonne documentation via commentaires (javadoc notamment) est indispensable.

En attendant, n’oubliez jamais, le code est écrit pour être lu !

It is quite frequent that maths structures, or more generally « established formalisms » as Eric Evans would say, are hidden everywhere in the business concepts we need to model in software.

Dates and how we take liberties with them for trading of financial instruments offer a good example of a business concept with an underlying math structure: traders of futures often use a notation like ‘U8′ to describe an expiry date like September 2018; ‘U’ means September, and the ’8′ digit refers to 2018, but also to 2028, and 2038 etc. Notice that this notation only works for 10 years, and each code is recycled every decade.

The IMM trading floor in the early 70′s (photo CME Group)

In the case of IMM contract codes, we only care about quarterly dates on:

• March (H)
• June (M)
• September (U)
• December (Z)

This yields only 4 possibilities for the month, combined with the 10 possible year digits, hence 40 different codes in total, over the range of 10 years.

How does that translate into source code?

As a software developer we are asked all the time to manage such IMM expiry codes:

• Sort a given set of IMM contract codes
• Find the next contract from the current « leading month » contract
• Enumerate the next 11 codes from the current « leading month » contract, etc.

This is often done ad hoc with a gazillion of functions for each use-case, leading to thousands of lines of code hard to maintain because they involve parsing of the ‘U8′ format everytime we want to calculate something.

With TDD, we can now tackle this topic with more rigor, starting with tests to define what we want to achieve.

The funny thing is that in the process of doing TDD, the cyclic logic of the IMM codes struck me and strongly reminded me of the cyclic group Z/nZ. I had met this strange maths creature at school many years ago, I had a hard time with it by the way. But now on a real example it was definitely more interesting!

Draw on established formalisms

Thanks to Google it is easy to find something even with just a vague idea of how it’s named, and thanks to Wikipedia, it is easy to find out more about any established formalism like Cyclic Groups. In particular we find that:

Every finite cyclic group is isomorphic to the group { [0], [1], [2], …, [n − 1] } of integers modulo n under addition

The Wikipedia page also mentions a concept of the product of cyclic groups in relation with their order (here the number of elements). Looks like this is the math-ish way to say that 4 possibilities for quarterly months combined with 10 possible year digits give 40 different codes in total.

So what? Sounds like we could identity the set of the 4 months to a cyclic group, the set of the 10 year digits to another, and that even the combination (product) of both also looks like a cyclic group of order 10 * 4 = 40 (even though the addition operation will not be called like that). So what?

Because we’ve just seen that there is an isomorphism between any finite cyclic group and the cyclic group of integer of the same order, we can just switch to the integer cyclic group logic (plain integers and the modulo operator) to simplify the implementation big time.

Basically the idea is to convert from the IMM code « Z3″ to the corresponding ‘ordinal’ integer in the range 0..39, then do every operation on this ‘ordinal’ integer instead of the actual code. Then we can format back to a code « Z3″ whenever we really need it.

Do I still need TDD when I have a complete formal solution?

I must insist that I did not came to this conclusion as easily. The process of TDD was indeed very helpful not to get lost in every possible direction along the way. Even when you have found a formal structure that could solve your problem in one go, even in a « formal proof-ish fashion », then perhaps you need less tests to verify the correctness, but you sure still need tests to think on the specification part of your problem. This is your gentle reminded that TDD is not about unit tests.

Partial order in a cyclic group

Given a list of IMM codes we often need to sort them for display. The problem is that a cyclic group has no total order, the ordering depends on where you are in time.

Let’s take the example of the days of the week that also forms a cycle: MONDAY, TUESDAY, WEDNESDAY…SUNDAY, MONDAY etc.

If we only care about the future, is MONDAY before WEDNESDAY? Yes, except if we’re on TUESDAY. If we’re on TUESDAY, MONDAY means next MONDAY hence comes after WEDNESDAY, not before.

This is why we cannot unfortunately just implement Comparable to take care of the ordering. Because we need to consider a reference IMM code-aware partial order, we need to resort to a Comparator that takes the reference IMM code in its constructor.

Once we identify that situation to the cyclic group of integers, it becomes easy to shift both operands of the comparison to 0 before comparing them in a safe (total order-ish) way. Again, this trick is made possible by the freedom to experiment given by the TDD tests. As long as we’re still green, we can go ahead and try any funky approach.

Try it as a kata

This example is also a good coding kata that we’ve tried at work not long ago. Given a simple presentation of the format of an IMM contract code, you can choose to code the sort, find the next and previous code, and perhaps even optimize for memory (cache the instances, e.g. lazily) and speed (cache the toString() value, e.g. in the constructor) if you still have some time.

In closing

Maths structures are hidden behind many common business concepts. I developed an habit to look for them whenever I can, because they always help make us think, they help question our understanding of the domain problem (« is my domain problem really similar in some way to this structure? »), and of course because they often offer wonderful ready-made implementation hints!

@tjaskula, the organizer of this new group, opened the evening with a welcome introduction. He also gave many suggestions of areas for discussion and debate.

A quick survey revealed that one third of the participants were new to Domain-Driven Design, while another third was on the other hand rather comfortable with it. This correlated with a rather senior audience, with only one attendee with less than 5 years experience and many 10+ years developers, including 22 years and 30 years experience developers, and still coding! If you work in Paris, I guess you know them already…

It was an open space session, so we first proposed a lot of topics for discussion with post-its on the wall: how to sell or convince about DDD, introduction on concepts, synchronizing between contexts…

We all decided to start with a walk through of the fundamentals of DDD: Bounded Contexts, Ubiquitous Language, Code as Model… It was great to have this two-way knowledge transfer between seniors and juniors, in an interactive fashion and with lot of questions, including some rather challenging and skeptical ones! There was also some UML bashing of course.

We concluded by eating Galettes des Rois, together with cider and beer, and a lot of fun. Thanks everyone for your questions and contributions, and see you soon on next meetup!

En programmation fonctionnelle, la programmation par continuation désigne une technique de programmation consistant à n’utiliser que de simples appels de fonction qui prennent pour argument leur propre continuation, au lieu d’appeler séquentiellement des fonctions, ou d’exécuter une fonction sur le résultat de la précédente. Ces fonctions se retrouvent en quelque sorte maîtresses de leur destin, et ne se contentent plus de subir le contexte.

Continuation ~ Wikipedia

Le schéma de pensée doit alors s’orienter vers une méthode de programmation plus fonctionnelle¹ que procédurale.
Bien que cela paraisse plus compliqué à mettre en place au départ, cela permet une souplesse et une modularisation beaucoup plus grande et une testabilité facilitée.

[1] Nous parlons ici de programmation fonctionnelle au sens de fonction uniquement et non son paradigme standard qui prône l’immutabilité des données. Une fonction devient un citoyen de premier ordre au même titre qu’une classe. Java n’ayant pas cette dimension, nous ferons une utilisation intensive des classes anonymes pour compenser cela.

Des fonctions passées en paramètre

(…) Un mécanisme puissant des langages fonctionnels est l’usage des fonctions d’ordre supérieur. Une fonction est dite d’ordre supérieur lorsqu’elle peut prendre des fonctions comme argument (aussi appelées callback) et/ou renvoyer une fonction comme résultat. On dit aussi que les fonctions sont des objets de première classe, ce qui signifie qu’elles sont manipulables aussi simplement que les types de base.

Programmation fonctionnelle ~ Wikipedia

Nous allons voir plusieurs techniques permettant de faciliter l’intégration d’une approche fonctionnelle à un code orienté objet. Le but n’est pas de tout écrire dans un paradigme ou un autre, mais simplement de voir comment une approche peut compléter et enrichir l’autre.
Après avoir défini nos techniques de bases, nous les appliquerons plus concrètement à différents cas d’utilisation.

Prenons comme base de travail une application qui gère des questionnaires (Quiz).

« Sans technique, la puissance n’est rien » — Aurait aussi pu dire le pneu

Notre application doit tout d’abord permettre de créer un questionnaire.
Afin de permettre la récupération du questionnaire créé, il est nécessaire de définir une fonction de rappel. Optons pour une approche générique et réutilisable (les noms des interfaces que nous définirons reprennent les noms standards que l’on retrouve en Haskell, Scala ou encore la librairie FunctionalJava.

public interface Effect< T> {
  void e(T value);
}

Cette interface décrit une méthode abstraite prenant un unique paramètre. Notre service pourra alors appeler cette fonction² avec le quiz qu’il aura tout juste créé.

[2] Nous utiliserons le mot « fonction » bien qu’elle ne renvoie aucun résultat et au risque d’en choquer certain nous n’utiliserons pas le mot procédure car il nous détournerait de notre vision: la lourdeur des procédures n’a d’intérêt que pour les fonctionaires.

La première version de notre service peut s’écrire:

public class QuizService {
  ...
  public void create(String quizContent, Effect<Quiz> effect) {
    Quiz quiz = quizFactory.create(nextId(), quizContent);
    effect.e(quiz);
  }
}

Notre service délègue la création du quiz à la fabrique (ligne 4). La fonction de rappel effect passée en paramètre est ensuite invoquée avec l’instance nouvellement créée (ligne 5).

Nous venons de voir notre première technique:

Première technique

Ajouter une fonction supplémentaire comme paramètre lors de l’appel d’une méthode. Cette fonction pourra alors être appelée avec le résultat du calcul lorsque celui sera disponible.

Imaginons maintenant que la construction d’une nouvelle instance de quiz nécessite plusieurs vérifications: il est impératif qu’un quiz soit unique (sinon il devient trop facile de tricher). Rajoutons pour cela un appel afin de vérifier cet invariant:

public class QuizService {
  public void create(String quizContent, Effect<Quiz> effect) {
    if(quizIsUnique(quizContent)) {
        Quiz quiz = quizFactory.create(nextId(), quizContent);
        effect.e(quiz);
      }
    }
}

Bon rien de très fantastique, si ce n’est un nouveau souci: que se passe-t-il si notre quiz n’est pas unique !?

C’est là que notre deuxième technique intervient!

Auparavant définissons une nouvelle interface générique permettant de décrire une alternative entre deux types de valeurs L et R. Il est de coutume d’appeler les différentes alternatives « Left » et « Right » (toute ressemblance avec un contexte politique est purement fortuite). Une instance de cette interface peut donc soit contenir une instance de type L soit une instance de type R.

public interface Either<L,R> {
  boolean isLeft();
  L left();
  boolean isRight();
  R right();
}

public class Eithers {
  public static <L,R> Either<L,R> left(L value) {
    return new Left(value);
  }
  public static <L,R> Either<L,R> right(L value) {
    return new Right(value);
  }
}

L’implémentation « Left » correspondante peut alors s’écrire:

public final class Left<L,R> implements Either<L,R> {
  private final L value;
  public Left(L value)    { this.value = value; }
  public boolean isLeft() { return true;  }
  public L left()         { return value; }
  public boolean isRight(){ return false; }
  public R right()        { throw new IllegalStateException("Sorry only left is allowed!"); }
}

On peux aisément en déduire l’implémentation « Right »:

public final class Right<L,R> implements Either<L,R> {
  private final R value;
  public Right(R value)   { this.value = value; }
  public boolean isLeft() { return false; }
  public L left()         { throw new IllegalStateException("Sorry only right is allowed!"); }
  public boolean isRight(){ return true;  }
  public R right()        { return value; }
}

Et un petit exemple avec une méthode qui divise un entier par un autre:

• soit le dénominateur est différent de zéro et tout va bien, la fonction renvoie le résultat
• soit le dénominateur est égale à zéro, la fonction renvoie alors un message indiquant que ça va pas

public static Either<Float,String> div(int numerator, int denominator) {
  if(denominator!=0) {
    float res = (float)numerator / (float)denominator;
    return Eithers.left(res);
  }
  else {
    return Eithers.right("Divide by zero error");
  }
}

Revenons à la création de notre quiz: soit il est unique et tout va bien soit il ne l’est pas et ça va pas… ça ressemble fort à notre alternative. Modifions alors la signature de notre fonction de rappel afin de prendre comme résultat une alternative: notre fonction de rappel Effect devient alors Effect<Either>.

public class QuizService {
  public void create(String quizContent, Effect<Either<Quiz,Failure>> effect) {
    if(quizIsUnique(quizContent)) {
      Quiz quiz = quizFactory.create(nextId(), quizContent);
      Either<Quiz,Failure> left = Eithers.left(quiz);
      effect.e(left);
    }
    else {
      // Failure is a Pojo but could also be an UniqueConstraintException
      Failure failure = new Failure(Code.NonUniqueQuiz);
      Either<Quiz,Failure> right = Eithers.right(failure);
      effect.e(right);
    }
  }
}

Soit le quiz est unique (ligne 3) dans ce cas l’alternative est construite avec le quiz – alternative left – (ligne 5) puis passée à la fonction de rappel (ligne 6). Dans le cas contraire, l’alternative est construite autour d’un code d’erreur – alternative right – (ligne 11) puis passée à la fonction de rappel (ligne 12).

Et voila notre deuxième technique:

Deuxième technique

La fonction de rappel est définie comme prenant un résultat dont le type peut varier en fonction du déroulement du calcul…

Un petit aperçu de code appelant:

quizService.create("<question4aChampion>...", new Effect<Either<Quiz,Failure>>() {
  public void e(Either<Quiz,Failure> res) {
    if(res.isLeft()) {
      Quiz quiz = res.left();
      displayFlashFeedback(quiz);
    }
    else {
      Failure failure = res.right();
      displayErrorFeedback(failure);
    }
  }
});

Lorsque la fonction de rappel est invoquée, soit l’alternative passée en paramètre contient un quiz (ligne 4) dans ce cas on affiche un beau message de retour avec le quiz créé. Sinon on affiche une notification d’erreur (ligne 9).

Ah, quelqu’un au fond de la salle a une remarque: « Comme il s’agit d’une erreur, pourquoi ne pas lancer une exception au lieu de faire une alternative, soit on a le résultat soit on lance une exception? »

Hummmm… eh bien sans trop anticiper sur la suite de l’article, il faut envisager que l’exécution du code de la méthode puisse être asynchrone.
Le contenu de la méthode s’exécute alors dans un autre fil d’exécution que le code qui l’a invoqué. Le code qui l’a invoqué continue à vivre son petit bonhomme de chemin et peut même ré-invoquer la même méthode, avant que la première exécution soit terminée. Si la méthode génère une exception, celle-ci sera dans le fil qui exécute le contenu de la méthode, l’appelant originel ne sera donc jamais informé, sauf si on ajoute un mécanisme du type UncaughtExceptionHandler qui se trouve n’être rien d’autre qu’une fonction de rappel appelée dans le cas d’erreur. En centralisant, les appels valides et invalides dans une unique fonction de rappel, le code est simplifié, ainsi que la vérification que notre fonction de rappel est appelée systématiquement.

Ok et la troisième technique alors? Nous y sommes presque!
Notre Quiz étant désormais créé, il faut le persister, et pour cela il nous faut une méthode pour le sauvegarder:

public class QuizService {
  public void save(Quiz quiz) {
    repository.save(quiz);
  }
}

Hummmm… une méthode sans retour, difficile de définir une fonction de rappel. Compliquons un peu les choses: la sauvegarde peut échouer et lancer une exception.

public class QuizService {
  public void save(Quiz quiz) {
    try {
        repository.save(quiz);
    }
    catch(RepositoryException re) {
        Failure failure = new Failure(re);
        ...
    }
  }
}

Nous nous retrouvons dans le cas précédent d’une alternative mais qui n’a qu’une seule possibilité, autrement dit un résultat optionnel: on a une erreur ou pas! Si tout se passe bien, on a pas de résultat, sinon on a une erreur. En s’inspirant de notre interface Either nous pouvons définir une nouvelle interface générique qui contient (ou pas!) quelque chose:

public interface Option<E> {
  boolean isSome();
  boolean isNone();
  E get();
}

public class Options {
  public static <E> Option<E> some(E value) {
    return new Some(value);
  }
  public static <E> Option<E> none() {
    return new None();
  }
}

Cette interface n’a que deux implémentations: une qui contient rien None et une qui contient quelque-chose Some.

L’implémentation « Some » peut alors s’écrire:

public final class Some<E> extends Option<E> {
  private final E value;
  public Some(E value)    { this.value = value; }
  public boolean isSome() { return true;  }
  public boolean isNone() { return false; }
  public E get()          { return value; }
}

L’implémentation « None »:

public final class None<E> extends Option<E> {
  public None() {}
  public boolean isSome() { return false;  }
  public boolean isNone() { return true; }
  public E get()          { throw new IllegalStateException("Sorry nothing to retrieve!"); }
}

Illustrons cela avec notre méthode de sauvegarde:

public class QuizService {
  public void save(Quiz quiz, Effect<Option<Failure>> effect) {
    try {
      repository.save(quiz);
      effect.e(Options.none());
    }
    catch(RepositoryException re) {
      Failure failure = new Failure(re);
      effect.e(Options.some(failure));
    }
  }
}

Si la sauvegarde se passe bien (pas d’exception) la fonction de rappel est appelée avec « rien »: Options.none() (ligne 5). Dans le cas contraire, l’exception est transformée en un objet plus adapté Failure et la fonction de rappel est appelée avec « quelque-chose »: Options.some(failure) (ligne 9).

Un petit aperçu de code appelant:

quizService.save(quiz, new Effect<Option<Failure>>() {
  public void e(Option<Failure> res) {
    if(res.isNone()) {
      displayFlashFeedback(Code.QuizSaved);
    }
    else {
      displayErrorFeedback(res.some());
    }
  }
});

Soit la fonction de rappel est appelée avec « rien » (ligne 3) dans ce cas on affiche un beau message indiquant que la sauvegarde s’est bien passée. Dans le cas contraire (ligne 6), l’objet Failure est récupérée et un message d’erreur est affiché.

Troisième technique

La fonction de rappel est définie comme prenant un résultat dont le contenu est optionnel

Avant d’exploiter tout cela, faisons un petit retour en arrière… Et si nous étions sûr que la sauvegarde se déroule toujours correctement, et que nous souhaitions juste être notifiés lorsque celle-ci a été réalisée, nous n’avons pas de technique pour cela! Effectivement, il n’y en a pas, mais l’on pourrait en ajouter une très simple: la fonction de rappel est définie comme ne prenant aucun argument et est invoquée lorsque l’action est arrivée au stade adéquat.
L’interface Runnable peut alors tout à fait correspondre à ce cas d’utilisation.

public class QuizService {
  public void save(Quiz quiz, Runnable onceSaved) {
    repository.save(quiz);
    onceSaved.run();
  }
}

Quatrième technique

La fonction de rappel est définie comme une fonction ne prenant aucun paramètre, elle est invoquée pour signaler que l’action désirée est effectuée

Pourquoi ne pas avoir parlé de cette technique auparavant: et bien tout simplement parce qu’il n’est généralement pas souhaitable de l’utiliser. En effet cette technique crée une ambiguïté: pourquoi notre fonction de rappel n’est pas appelée? la méthode a-t-elle oublié d’appeler la fonction de rappel, une erreur a modifié le fil d’exécution et le code n’appelle plus la fonction de rappel. En l’absence de retour, il n’est pas possible de réagir.

« The amateur software engineer is always in search of magic. » — Grady Booch

Continuons par une petite digression qui illustrera très simplement l’intérêt d’une approche par continuation plutôt que l’approche plus traditionnelle d’une méthode avec retour.

La création d’un quiz est une chose relativement complexe (si! si!) et peut prendre beaucoup de temps. Dans le cas d’une approche traditionnelle, l’appelant de notre méthode est donc en attente d’un retour, et son traitement est suspendu. Grâce à notre approche par continuation, il devient très facile de modifier le comportement de notre service afin de rendre ses traitements asynchrones, l’appelant peut alors continuer à effectuer ses propres tâches pendant ce temps.

Voyons comment rendre très simplement un service asynchrone avec Java Proxy. La méthode que nous allons voir repose sur les API du jdk, la seule limitation est que cela nous oblige à définir une interface pour notre service.

public interface QuizService {
  void create(final String quizContent, final Effect effect);
  void save(Quiz quiz, Effect<Option> effect);
}

Notre service peux devenir asynchrone grâce à l’appel suivant:

QuizService serviceImpl = new QuizServiceImpl();
QuizService asynService = Async.asyncProxy(QuizService.class,
                                           serviceImpl, executor);

Avec comme code pour notre classe utilitaire Async:

import java.lang.reflect.*;
import java.util.Arrays;
import java.util.concurrent.*;

public class Async {

  public static <T> T asyncProxy(Class type, T impl,
                                 ExecutorService executor) {
    return new Async(executor).asyncProxy(type, impl);
  }

  private final ExecutorService executor;
  public Async(ExecutorService executor) {
    this.executor = executor;
  }

  @SuppressWarnings("unchecked")
  public <T> T asyncProxy(Class<T> type, T impl) {
    return (T)Proxy.newProxyInstance(getClassLoader(),
                                     asArray(type),
                                     asyncHandler(impl));
  }

  private static <T> Class<?>[] asArray(Class<T> type) {
    return new Class[]{type};
  }

  protected ClassLoader getClassLoader () {
    return getClass().getClassLoader();
  }

  protected <T> InvocationHandler<T> asyncHandler(T impl) {
    return new AsyncHandler<T>(impl, executor);
  }

  private static class AsyncHandler<T> implements InvocationHandler {
    private final T impl;
    private final ExecutorService executor;

    public AsyncHandler(T impl, ExecutorService executor) {
      this.impl = impl;
      this.executor = executor;
    }

    @Override
    public Object invoke(Object proxy,
                         final Method method,
                         final Object[] args) throws Throwable {
      Future<Object> future = executor.submit(new Callable<Object>() {
        @Override
        public Object call() throws Exception {
          return method.invoke(impl, args);
        }
      });
      Class<?> returnType = method.getReturnType();
      if(returnType==null || returnType==Void.class)
        return null;
      else
        return future.get();
    }
  }
}

Quelques explications: un proxy est créé et implémente l’interface de notre service passée en paramètre type (ligne 18). Tous les appels effectués sur le proxy sont redirigés sur le InvocationHandler qui lui a été associé (ligne 21), et c’est là que les choses deviennent intéressantes: lignes 49 à 60.

L’appel de la méthode est transformé en un fragment executable (new Callable() {...}) qui est soumis à l’Executor correspondant. La méthode est alors invoquée de manière asynchrone (par rapport à l’appelant) sur l’instance de service qui a été transformé: impl (passée en paramètre ligne 18): l’appel effectif est déclaré ligne 52. Et là, soyons malin:

• soit la méthode invoquée ne renvoie rien void, dans ce cas le code appelant n’attend aucune valeur en retour, et il n’est pas nécessaire de rendre cet appel bloquant. On sort donc de la méthode (ligne 57) même si notre Callable n’a pas encore été executé ou s’il est en cours d’execution.
• soit la méthode invoquée renvoie quelque chose, dans ce cas le code appelant s’attend à un retour… il faut lui renvoyer quelque chose: le code appelant va donc être suspendu (future.get()) jusqu’à ce que le resultat soit disponible (ligne 59).

Bien entendu, nous nous arrangerons pour être toujours dans le premier cas si nous voulons que les appels soient toujours asynchrones.

Exemple de code appelant:

quizService.create("...", new Effect() {
  public void e(Quiz quiz) {
    displayFlashFeedback(quiz);
  }
});
// Quiz is being created...
// ... in the meanwhile let's display some waiting feedback
displayWaitingFeedback();

Nous voyons que sans modifier le code appelant, notre méthode par continuation a permis de brancher une implémentation asynchrone de notre service.

(On peux alors regarder le gars du fond de la salle et lui faire un petit hochement de tête complice!)

A voir aussi

• La gestion des erreurs avec scala.util.Try (1/2) – Nouhoum
• La gestion des erreurs avec scala.util.Try (2/2) – Nouhoum
• Error handling with Scala’s Try

• Either
  • Either ~ Haskell
  • Either ~ FunctionalJava
  • Either ~ Scala
  • Choice ~ F#
• Option
  • Maybe ~ Haskell
  • Option ~ FunctionalJava
  • Option ~ Scala
  • Option ~ F#

Let’s start with a tweet from earlier today :

If you follow the link, you’ll get to a Google Play application that allows you to play the (in-)famous RPSLS (Rock-paper-scissors-lizard-Spock) game. Why that tweet stroke me is that I had already played (with code !) around that game a few months ago…

Although this is just a variant of the classical rock-paper-scissors game, the two additional gestures shift the number of gesture combinations to 25, as shown on this matrix:

(image taken from http://en.wikipedia.org/wiki/File:Normal_form_matrix_of_Rock-paper-scissors-lizard-Spock.jpg)

There could be several ways to test these different combinations, for instance using the previous matrix as a reference, but… come on…. a closed set of values, and a simple behaviour… That’s just a perfect candidate for an enum ! And the best part is that I have actually implemented this as a test two months ago (proof on Github !).

Let’s first define the possible game outcomes :

Then we define the Gesture class and its values :

The trick here is that I changed the order of the values int the enum from Rock – paper – scissors – lizard – Spock to Rock – paper – scissors – Spock – lizard. This way, each values beats its predecessor and its second successor, and loses against its successor and second predecessor…

The behaviour can then be simply implemented based on the integer values of the enums :

Now we can write the tests in a very expressive way :

So… here is my answer to Leonard :

Surface-area over volume ratio?

I like the Surface-area over volume ratio as a metaphor to express how to make software cheaper to discover and learn, and smaller to maintain as well.

For a given object, the surface-area over volume ratio is the amount of surface area per unit volume. For buildings and for animals, the smaller this ratio, the less the heat loss during the winter, hence a better thermal efficiency.

Have you ever noticed that huge warehouses were always cool even during the summer when it’s hot? This is just because in our real 3D world the surface-area over volume ratio is much smaller when the absolute size of the building increases.

The theory also mentions that the sphere is the optimal shape with respect to this ratio. In fact, the more « compact » the less the ratio, or the other way round we could define compactness of an object directly by its surface-area-over-volume ratio.

A dodecahedron, a volume that approximates a sphere with just 2D facets (Wikipedia picture)

What about software design?

Let’s consider that each method signature of each interface is part of the surface-area of the software, because this is what I have to learn primarily when I join the project. The larger the surface-area, the more time I’ll need to learn, provided I can even remember all of it.

Larger surface is not good for the developers.

On the  other hand, the implementation is part of what I would call the volume of the software, i.e. this is where the code is really doing its stuff. The more volume, the more powerful and richer the software. And of course the point of Object Orientation is that you don’t have to learn all the implementation in order to work on the project, as opposed to the interfaces and their method signatures.

Larger volume is good for the users (or the value brought by the software in general)

As a consequence we should try to minimize the surface-area over volume ratio, just like we’re trying to reduce it when designing a green building.

Can we extrapolate that we should design software to be more « compact » and more « sphere »-like?

Facets-like interfaces

Reusing the same interface as much as possible is obviously a way to reduce the surface-area of the software. Adhering to interfaces from the JDK or Google Guava, interfaces that are already well-known, helps even better: in our metaphor, an interface that we don’t have to learn comes for free, like a perfectly isolated wall in a building. We can almost omit it in our ratio.

To further reduce the ratio, we can find out every opportunity to use as much as possible the minimum set of common interfaces, even over unrelated concepts. At the extreme of this approach we get duck typing in dynamic languages. In our usual languages like Java or C# we must introduce additional small interfaces, usually with one single method.

For example in a trading system, every class with a isInCurrency(Currency) method can implement a common interface CurrencySpecific. As a result, a lot of processing (filtering etc.) on stuff that is related to currencies in some way can be done on all these classes without any knowledge about them, except their currency-specificity.

In this example, the currency-specificity we extracted into one interface is like a single facet over a larger volume made of several implementation. It makes our design more compact, it will be easier to learn, while offering a rich set of behaviors.

The limit for this approach of putting a lot of implementation code under the same interface is that sometimes it really makes no domain sense. Since code is primarily meant to describe the domain, without causing confusion we must be careful not to go too far. We must also take great care when sharing interfaces between bounded contexts, there’s a high risk of excessive coupling.

Faceted artwork (picture from http://reinierdejong.wordpress.com)

Yet another metric?

This metric could be measured by a tool, however the primary value is not in checking the figures, but in the thinking and taking care of making the design easy to learn (less surface-area), while delivering a lot of valuable behaviors (more volume).

Have you ever tried to combine sequences in order to build Cartesian products in LINQ ? This is really easily achieved using the query expressions syntax, writing for instance :

When I write LINQ queries, I tend to use as often as possible the fluent syntax, as it is more powerful, and allows me to use a wider range of operators. I also try not to mix both syntaxes, because I find it quite confusing. When I want to perform, inside of a more complex query, a simple cross-product as the previous one, the “fluent” equivalent syntax is the following :

In fact, this syntax works very well, but I don’t find it as expressive as the first one. And if you go one step further and add a third sequence to the party…

The “fluent” syntax gets even more confusing (at least to me) :

I think that what bothers me might be the ever-increasing number of unclosed parenthesis… Anyway, as usual, I played with extensions methods and here is what I came up with, using a new “Cross” method, for the 2 sequences cross-product :

And the same syntax for the 3 sequences cross product :

Don’t you find it more expressive ?

Finally, here are the extensions methods implementations :

I must admit that those generic methods signatures are horrible, though…