Edit comme j'avais des doutes sur le benchmark lancé depuis Intellij, j'ai recodé un comparatif complet qui aura tourné 4 heures sur ma machine

Avec Kotlin, sous Java 21, en utilisant JMH, j'obtiens des résultats en total contradiction avec ceux obtenus via IntelliJ. L'écart passe de 12% à 2,2% dans le pire des cas.

Pour mon benchmark, j'ai calculé la longueur d'une String avec la fonction suivante : 2 * str.length + 1. Le but étant d'illustrer quel type d'appel est le plus rapide pour effectuer ce calcul.

Voici mes tableaux de comparatifs :

Conclusion après benchmark

Créer des instances à la Yegor Bugayenko semble être globalemment l'une si ce n'est la meilleure des solutions lorsque l'on observe son positionnement qui est au pire moyen sinon deux fois premier.

J'ai passé le nouvel an avec @Kysofer & @Chlouloutte. Quand tous les enfants ont le même âge c'est vraiment sympa ; surtout quand ils se couchent tous en même temps :P

Mais passons, ce matin après ce qui sera déjà l'une des plus courtes nuit de cette nouvelle année, je discute avec @Kysofer de ces projets pour 2024, il me sort un truc improbable :

Je pense que je vais abandonner la programmation orientée objet pour la programmation fonctionnelle...

Là, je le regarde limite choquée... Il faut dire que lui et moi partageons - je devrais dire partagions - le même avis sur la programmation fonctionnelle, notamment depuis nos déboires en OCaml (merci le programme de MPSI).

Donc, avec le plus grand respect je lui réponds :

Nani the fuck !?

À ma décharge je n'ai pas bu un seul verre d'alcool depuis la grossesse de ma petite dernière. Et oui. :P

Là il m'explique tout un tas de trucs et je dois dire que je me sens déstabilisée. Je m'explique, j'ai vécu trop de fois le fait de devoir maintenir du Scala pour savoir à quel point, sur le temps long, la programmation fonctionnelle pure devient encore moins maintenable que du Java + Spring Boot.

D'autant que je m'attendais à ce qu'il m'annonce qu'il allait (enfin) se monter un Shaarli.

Bref son idée est dirigée par les contraintes suivantes :

• Avoir un code dirigé par des contrats (au sens interfaces Java) dont le respect du typage est prouvé lors de la compilation et garanti lors de l'exécution.
• Ne pas avoir besoin de créer des instances techniques qui implémentent ces contrats, afin d'encapsuler des données dedans.
• Parvenir quand même à encapsuler les données pour les protéger mais sans jamais créer de nouvelles instances (cf. le point précédent).
• Avoir les mêmes performance d'exécution que du chaînage d'appels de fonctions static ; et donc l'eldorado du zero GC-time.
• Permettre une exécution différée/lazy/paresseuse.

Quand on lit le truc, on se dit que la vie n'est plus à un paradoxe prêt, mais pourtant sa façon de faire fonctionne.

Je vais essayer de vous décrire ce qu'il m'a expliqué afin de mieux l'ingérer moi-même.

Exemple : Déterminer si deux trucs sont égaux

Dans tous les cas de figure, nous allons supposer que les données sont décorées par une implémentation de l'interface suivante qui permet de les représenter sous la forme d'un tableau d'octets.

interface RawData {

    fun asBytes():ByteArray

}

Version OOP Pure

1) On exprime le concept de vérification via une interface :

interface Check {

    fun status():Boolean

}

Ensuite on fournit une implémentation de l'interface Check qui soit spécialisée dans la comparaison de deux RawData :

class IsEqual(
    private val left:RawData,
    private val right:RawData
):Check {

    override fun status():Boolean {
        return this.isSameInstances() || this.haveSameBytes()
    }

    private fun haveSameBytes():Boolean {
        return left.asBytes().contentEquals(right.asBytes())
    }

    private fun isSameInstances():Boolean {
        return left === right
    }

}

Et ça s'utilise comme ceci :

val left:RawData = StrAsData("same data")
val right:RawData = StrAsData("same data")

val comparison:Boolean = IsEqual(left, right).status()

Problème
Pour comparer deux objets on doit forcément créer une instance de IsEqual puis invoquer une méthode dessus. Sur JRE, c'est ~12% de temps de calcul supplémentaire par rapport à un simple appel de méthode statiques !

Version PF pure

Avant toute chose, il faut comprendre ce qu'est un contrat pour @Kysofer. C'est un truc qui va prouver à la compilation que les types d'entrée et de sortie soient bien respectés, ce qui fait que l'implémentation A pourra se substituer à l'implémentation B sans problème lors du runtime.

Mais comment peut-on produire l'équivalent d'une interface en PF ?

=> On passe par des fonctions de premier ordre.

En effet, une méthode qui reçoit une fonction de premier ordre ne sait pas ce qu'elle va exécuter. Elle sait juste que la fonction prendra un certain type en entrée et un certain type en retour. Le reste, c'est le compilateur qui agit.

Si l'on reprend l'interface Check cela nous donne le prototype suivant :

val prototype:() -> Boolean

C'est-à-dire un Predicat sans paramètre.

Maintenant passons à l'implémentation naïve, ceci nous donne :

fun isEqual(left:RawData, right:RawData):() -> Boolean {
    return {
        isSameInstances(left, right) || haveSameBytes(left, right)
    }
}

private inline fun haveSameBytes(left:RawData, right:RawData):Boolean {
    return left.asBytes().contentEquals(right.asBytes())
}

private inline fun isSameInstances(left:RawData, right:RawData):Boolean {
    return left === right
}

On voit bien que la fonction isEqual(..) retourne une fonction de premier ordre qui elle-même retournera un Boolean.

Rappel
En Kotlin, les lambda sont déclarées entre deux accolades { .. }.

Sauf que cet exemple a un problème puisqu'une lambda, sur JRE tout du moins, c'est une instance de l'interface Function ou l'un de ses équivalents. Bref, il n'y a pas de gain en terme de performance par rapport la version OOP.

Pour l'obtenir, il suffit de remplacer la création d'une lambda par un pointeur sur une fonction anonyme, ce qui nous donne :

fun isEqual(left:RawData, right:RawData) = fun():Boolean {
    return isSameInstances(left, right) || haveSameBytes(left, right)
}

Et la ça devient magique car la fonction anonyme étant écrite directement dans le byte-code et épinglée une et une seule fois en mémoire, cela revient à avoir un pointeur sur fonction qui exécutera la-dite fonction.

=> Soit un gain de 12% en termes de performance, ce qui fait qu'on rattrape la vitesse d'exécution d'un chaînage de méthodes statiques.

Mieux que cela, @Kysofer s'appuie sur une variante de la Curryfication . En effet, la méthode isEqual(..) sert à encapsuler les données dans la pile d'appel pour les rendre utilisables que par la fonction anonyme. Donc il devient impossible de savoir ce qui sera utilisé par la lambda qui sera retournée.

=> Les paramètres left et right sont bien encapsulés dans la lambda !

Si on résume

• Le fait que la fonction isEqual(..) retourne une lambda et non un résultat fait que l'on va déclarer un contrat et donc rendre les lambda interchangeables.
• Le fait que l'on retourne une fonction et non un résultat permet un calcul différé/paresseux potentiellement dans un autre thread.
• Le fait que l'on passe par une fonction anonyme qui utilisera les paramètres de la fonction déclarée fait qu'on encapsulera bien les données avant d'exécuter quoi que ce soit dessus.
• Le fait que tout soit fonction garanti l'absence de création d'instances techniques.

Nous avons donc bien là une version fonctionnelle de l'encapsulation et des contrats de l'OOP.

Ça aura pris 15 ans mais je pense être réconciliée totalement avec la PF (O_O) ; sauf le récursif, ça jamais ! En tout cas pas avant une démonstration comme celle-ci :P

J'ai vécu une phase comme ça, entre 2014 et 2016 où ça devenait penible pour moi de coder. J'avais même accepté un job de chef de projet en 2015 c'est dire ! À cette époque, j'avais l'impression d'avoir fait le tour de la question, toutes les applications avaient tout le temps les mêmes couches, avec les mêmes frameworks et systématiquement le code technique et les classes anémiques prédominaient.

Puis j'ai redécouvert la programmation fonctionnelle (la vraie, pas celle de Java) mais aussi la programmation orientée objets (la vraie aussi, pas celle de Java) alors que j'étais pourtant sûr et certaine de maîtriser l'une et l'autre.

J'ai alors accepté l'idée que je ne savais coder ni dans l'une ni dans l'autre et que tout ce qui m'était présenté comme des "patterns" embarqués out-of-the-box par des frameworks comme Spring Boot étaient en réalité des anti-patterns et souvent parmi les pires !

J'ai commencé à détester coder à cette époque parce que le code était devenu une procédure à dérouler dans une architecture normée, pensée et plébiscitée par des non-développeurs que le marché appelait "architectes" et cela m'ôtait toute possibilité de réfléchir à comment faire et surtout de faire mieux que ces tripotés d'ingénieurs-cadres hélicoptères ne sachant plus trier une liste.

Ce qui m'a redonner l'envie de coder ce fût la découverte de Kotlin en 2015, de Yegor Bugayenko à la même époque et les cours de Kysofer qui a passé des week-ends entiers à me faire découvrir tout un tas de choses notamment :

• Pourquoi et en quoi l'API stream de Java 8 n'était pas du tout de la programmation fonctionnelle.
• Pourquoi je n'avais jamais créé ni utilisé le moindre objet au sens OOP du terme avec JPA ou des DTO.
• En quoi la composition vs héritage n'était pas du tout ce que je pensais et ce qu'internet disait.
• Pourquoi si j'avais du mal à écrire des tests c'était à cause des architectures procédurales et qu'en réalité c'était facile et que j'adorais ça.
• En quoi écrire la doc était une perte de temps mais était obligatoire à cause des architectures orientées techniques et non métier.

Et tellement d'autres choses. @Kysofer tu avais raison quand tu me disais : " j'adore mon métier, mais je déteste mon travail ".

Bref si vous ne codez plus, quittez l'IT, les meilleurs entraîneurs sont ceux qui ont boxé jusqu'au bout, pas ceux qui n'ont fait ca que 4 ou 5 ans.

J'ai été très critique sur le code proposé par Collin Damon car en voulant montrer ce qu'est la OOP le seul exemple qu'il donne d'API à se fabriquer est entièrement statique.

Je reprends donc son exemple et je vais tenter de le rendre objet :

public final class Assert {

  private Assert() {}

  public static void notNull(String fieldName, Object input) {
    if (input == null) {
      throw MissingMandatoryValueException.forNullValue(fieldName);
    }
  }

  public static void notBlank(String fieldName, String input) {
    if (input == null) {
      throw MissingMandatoryValueException.forNullValue(fieldName);
    }

    if (input.isBlank()) {
      throw MissingMandatoryValueException.forBlankValue(fieldName);
    }
  }

  public static StringAsserter field(String fieldName, String value) {
    return new StringAsserter(fieldName, value);
  }
  public static class StringAsserter {
    private final String fieldName;
    private final String value;
    private StringAsserter(String fieldName, String value) {
      this.fieldName = fieldName;
      this.value = value;
    }
    public StringAsserter notBlank() {
      Assert.notBlank(fieldName, value);
      return this;
    }
    public StringAsserter maxLength(int maxLength) {
      if (value != null && value.length() > maxLength) {
        throw StringSizeExceededException
            .builder()
            .field(fieldName)
            .currentLength(value.length())
            .maxLength(maxLength).build();
      }
      return this;
    }
  }
}

Étape 1 - Créer une interface qui va exprimer ce que l'on compte faire :

public interface Assertion {
    boolean isValid();
}

Étape 2 - Fournir une implémentation pour chaque use case :

Cas de la chaîne de caractères null :

/**
 * Cette classe prend un `Object` pour rendre générique le test de nullité.
 */
public final class NotNull implements Assertion {
    private final Object value;

    public NotNull(Object value) {
        this.value = value;
    }

    @Override
    public boolean isValid() {
        return this.value != null;
    }
}

Cas de la chaîne de caractères vide :

/**
 * Il faudra fournir une implémentation de NotEmpty par type testé,
 * ce qui peut sembler lourd mais qui a du sens puisque la notion de
 * nullité peut changer en fonction du type. Par exemple, une String
 * vide n'est pas la même chose qu'un tableau vide.
 */
public final class NotEmpty implements Assertion {
    private final String value;

    public NotEmpty(String value) {
        this.value = value;
    }

    @Override
    public boolean isValid() {
        return !this.value.isEmpty();
    }
}

Étape 3 - Ajout de la composition

L'assertion composée est elle aussi une implémentation de l'interface Assertion et ne prend que des Assertion en paramètre.

public final class Assertions implements Assertion {
    private final Assertion[] assertions;

    public Assertions(Assertion... assertions) {
        this.assertions = assertions;
    }

    @Override
    public boolean isValid() {
        return Arrays.asList(this.assertions).stream().allMatch {
            (Assertion it) -> is.isValid();
        }
    }
}

Étape 4 - Un exemple d'utilisation

public class Main {
    public static void main(String... args) {
        String toto = "titi";

        new Assertions(
            new NotNull(toto),
            new NotEmpty(toto)
        ).isValid();
    }
}

Dans cet exemple, aucun calcul n'est effectué dans le constructeur et tous les déclenchements sont joués uniquement au moment de l'invocation de la méthode isValid() (on est donc en lazy evaluation), chaque objet possède un à état, tous les attributs sont immutables et les classes aussi (car final), il y a zéro héritage et uniquement de la composition, tout a été codé en interface-first pour s'abstraire des implémentations, enfin les classes étant rikiki, elles sont ultra-simples à tester.

Edit : en Kotlin le mot-clef new disparait car le langage assume qu'un constructeur soit une fonction static à scope global (ce qui est le cas dans le bytecode de Java), du coup la chaîne d'instanciations apparaît comme une composition de fonctions (au sens f o g(x) ou f(g(x))) sans avoir besoin de passer par une fluent API et une monade.

Article mis sous le coude pour tout à l'heure.

Sur une idée de @Kysofer, je reprends mon post précédent pour mettre à jour l'exemple que j'avais donné afin de l'améliorer et de le simplifier.

L'idée est de se débarrasser des méthodes 'static' de chaque structure que j'avais appelées "new" pour les remplacer par des fonctions globales (globales au niveau du module) à côté des structures et dont le nom est plus porteur de sens. (ndr. elles remplacent les constructeurs nommés de Yegor Bugayenko en prenant un petit peu de la Factory Method défendue par Joshua Bloch).

L'intérêt des d'avoir des objets concrets qui profitent tout de suite du polymorphisme d'une interface (ici "Addition") et de wrapper ces instances dans une Box<dyn T> pour être réutilisées ailleurs, y compris dans une struct. Cela découple totalement les liens entres les instances puisque seules les types des interfaces fuitent.

Si à cela on ajoute l'immutabilité totale et l'absence de getter/setter, alors cela commence à être du vrai FOP (Functional-Object Programming) dont la base s'appuie sur la notion d'Elegant Objects.

Je suis contente de savoir à présent allier parfaitement paradigmes fonctionnel et objet alors qu'ils m'ont toujours été présentés comme deux antagonistes.

L'étape suivante sera de compléter l'exemple pour effectuer le même calcul en multi-thread et tirer 100% de la puissance de Rust. @Kysofer, si tu as l'envie de m'aider :P

#![allow(non_snake_case)]
// Exécution
fn main() {
    let additionA = AdditionFromCouple(1, 2);
    println!("Couple add  : [{}]", additionA.add()); // Print 3

    // Ne pas oublier de wrapper Couple dans une Box
    let additionB = AdditionFromTriplet(additionA, 3);
    println!("Triplet add : [{}]", additionB.add()); // Print 6
}

// Traits
trait Addition {
    fn add(&self) -> i32;
}

// Structures
struct Couple {
    opA: i32,
    opB: i32,
}
struct Triplet {
    opA: Box<dyn Addition>,
    opB: i32,
}

// Implémentations
impl Addition for Couple {
    fn add(&self) -> i32 {
        return self.opA + self.opB;
    }
}

impl Addition for Triplet {
    fn add(&self) -> i32 {
        return (*self.opA).add() + self.opB;
    }
}

// Factory Methods (Utilisées comme constructeurs) 
fn AdditionFromCouple(opA: i32, opB: i32) -> Box<dyn Addition> {
    return Box::new(Couple { opA: opA, opB: opB });
}

fn AdditionFromTriplet(opA: Box<dyn Addition>, opB: i32) -> Box<dyn Addition> {
    return Box::new(Triplet { opA: opA, opB: opB });
}

@Sweet le 9 c'est le plus compliqué quand on vient du procédurale et qu'on essaie de faire de l'OOP (note : l'API Java est procédurale à 99%).

Je l'ai compris grâce à des formations que des copains d'ITAMETIS m'ont offertes (merci @Kysofer pour tout le temps que tu as passé à m'appendre). En substance, dès qu'une classe affiche un getter ou un setter, alors son développeur a violé le principe d'encapsulation, ce qui est "anti-objet" par nature.

Dit autrement, nous mettons des get/set pour avoir bonne conscience mais nous pourrions les remplacer par des attributs public cela reviendrait exactement au même. En ajoutant des getter/setter nous exposons deux choses en les sortant de l'encapsulation :

1. La valeur de la donnée
2. Le type réel de la donnée (c'est de loin le pire)

Et ce type d'objets s'appelle : une structure de données. Les méthodes des autres objets appelant les get/set n'étant que des procédures décidant quoi mettre et quoi retirer de ces objets structures de données.

Alors cela m'a pris un bon moment avant de comprendre comment coder sans setter (pour l'immutabilité de la programmation fonctionnelle) et sans getter (pour respecter l'encapsulation de la programmation orientée objets) ; et bien sûr sans jamais remplacer l'un ou l'autre par des attributs publics. C'est ce que j'entends lors que j'écris "programmer en interface-first".

Le meilleur bouquin que je puisse te recommander à ce sujet est Elegant Objects de Yegor Bugayenko. C'est un solid 5/7 au niveau de la "disruptivité". Mais si tu fais du Java par exemple, alors tu devrais comprendre pourquoi ceux qui font "du vrai" OOP (pardon pour l'expression mais c'est à prendre au sens "ne violant jamais l'encapsulation") disent que Spring n'est pas orienté objet pour un sou et que le framework pousse à de la programmation procédurale comme en C ou VB.

Après c'est mon côté coach crafts qui incite toujours à mieux comprendre un paradigme de programmation et d'expérience maintenant, la grande majorité des développeurs ne creusent pas plus loin que les 75% d'un concept (ça descend en dessous des 20-25% pour l'objet et le fonctionnel car les "frameworks s'en occupent pour nous") et puis il faut aussi admettre que le procédurale est bien plus accessible quand on veut produire vite, même s'il est nettement moins maintenable.

Alors ce tutoriel est très bien pour ceux qui souhaitent apprendre la syntaxe du langage par contre en aucun cas il ne correspond au titre de l'e-book dont il est un chapitre : "Introduction au langage Kotlin, découvrir les notions avancées de la programmation orientée objet".

En rien l'article ne parle d'OOP et de ses concepts avancés, bien au contraire il met en avant les aspects du langage qui poussent à la programmation procédurale réalisée à partir de structures de données façon C/VB/PL-SQL et je m'explique.

Lorsque vous créez une classe avec des getters et des setters, vous ne faites ni plus ni moins que de créer une structure avec des attributs public déguisés en attributs privés. Fondamentalement, même si c'est au travers d'une méthode, vous permettez à n'importe quelle autre classe de violer l'aspect le plus fondamental de l'OOP : l'encapsulation (je vous invite à suivre les tutos de @Kysofer sur le sujet, c'est un grand gourou du domaine).

D'ailleurs, et pour reprendre l'un de ses cours, l'encapsulation c'est deux composantes :

1. Personne d'autre que la classe ne peut connaître (et encore moins modifier) les données qu'elle contient.
2. Personne d'autre que la classe ne peut connaître le type réel des données qu'elle contient.

Avec un exemple simple, si j'ai cette horreur (du point de vue de l'OOP) :

val name:String = person.getName()`
person.setName("my-name")`

Alors cela revient exactement au même que d'écrire :

val name:String = person.name`
person.name = "my-name"

Cela est tellement la même chose que Kotlin l'assume et génère à la compilation, à partir des getters/setters, le code du second exemple pour permettre l'accès en public aux attributs.

Mais là n'est pas le problème, en effet le vrai problème est que si je venais à changer le type interne de name pour le passer d'une String à un nouveau type, par exemple appelé Name, alors il faudra que je modifie TOUS LES APPELS EFFECTUÉS à getName() car les codes appelant s'attendent à une String, rien n'est encapsulé, rien n'est masqué, a contrario toute la représentation interne fuite à travers les getters/setters et les gens appellent cela innocemment de l'OOP alors que ça n'en est pas du tout : ce sont des struct déguisées en objets.

La solution consiste à n'utiliser que des interfaces car par essence, une interface ne peut pas avoir d'attributs. Alors certes les dérives depuis Java 8 et certains anti-patterns de la programmation fonctionnelle (du point de vue de l'OOP toujours) ont eu tendance à modifier le langage mais dans la pratique, c'est vraiment une très mauvaise idée de mettre des attributs/constantes dans une interface.

Je sais que @Kysofer et @Lenny réfléchissaient à faire des tutos sur l'OOP sur Youtube/PeerTube, j'espère que ce post va les motiver à passer à l'acte. D'ailleurs je partagerai toutes vos vidéos mes chéris :) #Waiting

Remarque :

• Le concept de cache ici pose problème puisque des méthodes qui transforment (à base de verbes) retournent en réalité quelque chose.
• Les méthodes avec des boolean ont des verbes, c'est une exception à la Yegorification du code.

// Usage :
object Main {
    fun regularUseCase() {
        // Given
        val christmas = LocalDate(2019, 12, 25)
        val calendar:HolidaysCalendar = HolidaysCalendarForYear(Year(2019))

        // When
        val daysOff:DateSet = calendar.daysOff()

        // Then
        println(daysOffs.contains(christmas))       // print true
    }

    fun cachedUseCase() {
        // Given
        val christmas = LocalDate(2019, 12, 25)
        val cache:Cache = HolidaysCalendarCache()

        // When
        val daysOff2:HolidaysCalendar = cache.value(Year(2019))
        val daysOff3:HolidaysCalendar = cache.value(Year(2019))

        // Then
        println(daysOff2.contains(christmas))       // print true
        println(daysOff2 === daysOff3)              // print true (same instance)
    }

    @JvmStatic
    fun main() {
        val main = Main()
        main.regularUseCase()
        main.cachedUseCase()
    }
}

// Interfaces
interface DateSet {
    /**
     * Determine whether or not the specified date is in this set.
     *
     * @param date
     *          The date to research.
     *
     * @return true if the date exists in this set, false otherwise.
     */
    fun contains(date:LocalDate):Boolean

    /**
     * Determine whether or not the specified date is in this set.
     *
     * @param date
     *          The date to research.
     *
     * @return true if the date exists in this set, false otherwise.
     */
    fun contains(date:Calendar):Boolean

    /**
     * Return the current set of date as an iterable collection.
     *
     * @return A collection having all the date stored in this set.
     */
    fun asCollection():Collection<LocalDate>
}

interface HolidaysCalendar {
    /**
     * Return a set of holiday dates.
     *
     * @return All holidays for a period (see implementation for more detail).
     */
    fun daysOff():DateSet

    /**
     * The period covered by this calendar.
     *
     * @return Something in the CalenadrPeriod enumeration.
     */
    fun range():CalenadrPeriod
}

class Cache<K, V> {
    /**
     * Determine whether or not the specified value exists in this cache.
     *
     * @param value
     *          The value to search.
     *
     * @return true if the value has been found, false otherwise.
     */
    fun contains(value:V):Boolean

    /**
     * Determine whether or not a key exists in this cache.
     *
     * @param key
     *          The key to search.
     *
     * @return true if the key exists, false otherwise (reminder: a key cannot exists if linked to nothing).
     */
    fun containsKey(key:K):Boolean

    /**
     * Retrieve the value related to the specified key.
     *
     * @param key
     *          The key related to the researched value.
     *
     * @return The value related to the given key.
     *
     * @throw UnexistingEntryException
     *          When the subsystem cached by this object is not able to restitute a value using the specified key.
     */
    fun value(key:K):V

    /**
     * The list of keys used by this cache.
     *
     * @return The list of keys used by this cache.
     */
    fun keys():List<K>

    /**
     * Remove the specified key in order to force an update.
     *
     * @param key
     *          The key of the cache entry to remove.
     */
    fun remove(key:K)

    /**
     * Clear all entry is the current cache.
     */
    fun reset()
}

// Implementation of HolidaysCalendar
class HolidaysCalendarForYear(private val year:Year):HolidaysCalendar
class HolidaysCalendarForMonth(private val year:Year, private val month:Month):HolidaysCalendar

// Implementation of Cache
class HolidaysCalendarCache:Cache<Year, HolidaysCalendar>

Je trolle un peu mais je subodore que cela fût écrit par des devs C ou éventuellement Scala / Haskell / Lisp.

Une fonction prenant autant la terre entière en paramètre, notamment avec des algo-switchers (boolean) est typique des personnes qui pensent structures et non ségrégation et en encapsulation.

Clean-coder est difficile, l'OOP l'est aussi, la PF également alors allier les trois correctement...

Rust est un langage orienté fonctionnel, de ce fait il lui manque une encapsulation forte dans des classes pour utiliser de l'OOP (il est très proche de C++ sur ce point). Mais il est possible de faire quelque chose de sympa avec les Traits :

trait Quack {
    fn quack(&self);
}

struct Duck ();

impl Quack for Duck {
    fn quack(&self) {
        println!("quack!");
    }
}

struct RandomBird {
    is_a_parrot: bool
}

impl Quack for RandomBird {
    fn quack(&self) {
        if ! self.is_a_parrot {
            println!("quack!");
        } else {
            println!("squawk!");
        }
    }
}

let duck1 = Duck();
let duck2 = RandomBird{is_a_parrot: false};
let parrot = RandomBird{is_a_parrot: true};

let ducks: Vec<&Quack> = vec![&duck1,&duck2,&parrot];

for d in &ducks {
    d.quack();
}
// quack!
// quack!
// squawk!