Produire du "Clean Java Code" via Lambdas

En tant que développeurs, nous nous comportons comme des enfants. Quand nous voyons de nouvelles choses brillantes, nous cherchons juste à jouer avec. C'est normal, accepté, et en général, bénéfique pour notre travail ... jusqu'à un certain point.

Lorsque Java a commencé à fournir des annotations avec la version 5, il y avait un énorme mouvement vers leur utilisation. (Nulle part, partout). Même que ce n'était pas une bonne idée. Mais c'était nouveau, donc ça devait être bon. Bien sûr, quand quelque chose est maltraité, il y a un mouvement fort contre cela. De sorte que même lorsque l'utilisation d'annotations peut avoir du sens, certains développeurs peuvent être fortement contre.

Malheureusement, nous n'avons pas appris collectivement des annotations excessives. Beaucoup d'entreprises ayant migré vers Java 8, on commençait à remarquer beaucoup de code utilisant des lambdas comme celui-ci:

List persons = ...;
persons.stream().filter(p -> {
    if (p.getGender() == Gender.MALE) {
        return true;
    }
    LocalDate now = LocalDate.now();
    Duration age = Duration.between(p.getBirthDate(), now);
    Duration adult = Duration.of(18, ChronoUnit.YEARS);
    if (age.compareTo(adult) > 0) {
        return true;
    }
    return false;
}).map(p -> p.getFirstName() + " " + p.getLastName())
  .collect(Collectors.toList());

C'est juste un échantillon, mais ça donne une bonne idée du code qu'on retrouve. C'est en général plus long et encore plus compliqué, ou pour être politiquement correct, il y a place à amélioration - vraiment beaucoup de place.

Le premier mouvement serait d'appliquer une dénomination correcte, ainsi que de déplacer la logique à l'endroit auquel elle appartient.

public class Person {

    // ...

    public boolean isMale() {
        return getGender() == Gender.MALE;
    }

    public boolean isAdult(LocalDate when) {
        Duration age = Duration.between(birthDate, when);
        Duration adult = Duration.of(18, ChronoUnit.YEARS);
        return age.compareTo(adult) > 0;
    }
}

Ce petit refactoring améliore déjà la lisibilité du lambda:

persons.stream().filter(p -> {
    if (p.isMale()) {
        return true;
    }
    LocalDate now = LocalDate.now();
    if (p.isAdult(now)) {
        return true;
    }
    return false;
}).map(p -> p.getFirstName() + " " + p.getLastName())
        .collect(Collectors.toList());

Mais cela ne devrait pas s'arrêter là. Il y a une analyse intéressante de l'impact sur le métier concernant les expressions Lambdas: elles doivent être anonymes. Presque tous les exemples sur le Web montrent des lambdas anonymes. Mais rien ne pouvait être plus éloigné de la vérité!

Nommez les Lambdas, et vérifiez les résultats:

// Implementation details
Predicate isMaleOrAdult = p -> {
    if (p.isMale()) {
        return true;
    }
    LocalDate now = LocalDate.now();
    if (p.isAdult(now)) {
        return true;
    }
    return false;
};
FunctionString

> concatenateFirstAndLastName = p -> p.getFirstName() + " " + p.getLastName(); // Core

Rien de stupéfiant! 

Pourtant, notez que le flux lui-même (la dernière ligne) est devenu plus lisible, pas caché derrière les détails de mise en œuvre. Cela n'empêche pas les développeurs de les lire, mais seulement si nécessaire.

Conclusion

Les outils sont des outils. Les Lambdas en font partie, dans la gamme d'outils d'un développeur Java.