• Développement
• Tool in action
• Standard
• 25 min

On touche pas son père : sortir de l’héritage avec la délégation Kotlin

• Date jeudi
• Horaire 15h35 à 16h00
• Salle Amphi B

Description

Quand on jouait au loup dans la cour d’école, il y avait une règle tacite : “on touche pas son père” — on ne retouche pas celui qui vient de nous toucher, sinon la partie tourne en boucle. En code, beaucoup d’équipes finissent par appliquer la même règle à la classe mère : “ne touche pas au parent, tu vas tout casser”. Et c’est souvent le signe de bugs dans la Matrice : couplages implicites, effets de bord, overrides surprenants… et, au passage, des glissements progressifs vers des violations des principes SOLID. Dans cette session, je propose une autre approche : remplacer l’héritage utilisé pour partager du comportement par de la composition et de la délégation en Kotlin (by). L’idée est simple : au lieu d’empiler des responsabilités dans une hiérarchie de classes, on construit des services “en couches” (wrappers / décorateurs) qui ajoutent chacun un comportement précis, tout en déléguant le reste. À travers quelques refactorings “avant / après”, on verra comment cette approche rend les responsabilités plus explicites, facilite les tests, et permet d’évoluer sans créer de nouvelles classes de base ni de hooks implicites — avec une méthode de migration progressive, applicable sur une base existante.

Orateur·ices

Thomas Martin

Tech Lead backend chez Whoz après 10 ans en ESN. Je suis toujours à la recherche de simplicité dans les solutions. Mon langage de prédilection est Kotlin.

Actions rapides

🎥 Voir la vidéo mettre en favoris Ajouter à Google Calendar Télécharger le fichier ICS

Partager la session

---

Les sessions futures sur le même thème

• • Développement
  • Tool in action

  Le plus dur, c'est de commencer...

  En attente de mission, je lance mon side-project : serendipitech.fr J'avais l'idée générale : répertorier les conf' en France et proposer une alerte email à ceux qui le souhaite pour être prévenu des nouvelles dates, ouverture des billetteries ou CFP. OK. La stack je l'avais aussi, je voulais continuer d'avancer sur mes acquis : du Spring Boot avec Kotlin et Vue.js en front. Pour l'infra, je voulais mettre mon appli en Docker bien sûr, et un voisin avait un vieux serveur dans un placard, autant que ça serve. Installation d'Ubuntu. Hop, c'est bon. And now what ?! Goutte de sueur sur le front... je commence par quoi ? Le front ? Le back ? Installer Docker ? Acheter mon nom de domaine ? C'est quoi mon premier commit ? C'est quoi ma première feature ? Ahhh. Panique. Mais promis, ça n'a pas duré. J'ai réussi à me lancer. Envie d'en savoir plus ? De savoir si mon serveur à cassé et j'ai plutôt déployé proprement dans le cloud (spoiler : oui) ? Rex décomplexé d'un side project. Pour oser se lancer, prendre du recul sur les différentes briques d'une application et se poser les bonnes questions.

  Vendredi 8h30 à 9h25 - Amphi C
• • Développement
  • Quicky

  Le hasard fait bien les tests

  > Le hasard fait bien les choses. Si on applique cette idée aux tests unitaires ou aux tests d'intégration, on peut rendre nos tests beaucoup plus imprévisibles et du coup trouver des problèmes que notre esprit n'aurait jamais osé imaginer ! Par exemple, récemment, j'ai découvert dans une bibliothèque de gestion de configuration, [un bug](https://github.com/gestalt-config/gestalt/issues/242) qui se produit lorsque la `Locale` est configuré en `AZ`. 🤦🏼‍♂️ Un autre exemple encore plus simple : ```java int input = generateInteger(Integer.MIN_VALUE, Integer.MAX_VALUE); int output = Math.abs(input); ``` Peut générer `-2147483648`... Ce qui est assez inattendu pour une valeur absolue ! 😉 Les tests aléatoires peuvent découvrir ces cas tordus... C'est ce que l'équipe elasticsearch a mis en place depuis plusieurs années à l'aide du framework [RandomizedTesting](https://labs.carrotsearch.com/randomizedtesting.html) pour tester tout le code Java. Ajoutez à ça de vrais tests d'intégration à l'aide de [TestContainers](https://java.testcontainers.org/modules/elasticsearch/) et vous aurez une approche complète pour des tests qui échouent régulièrement ! Après cette conférence, vous ne verrez plus jamais la fonction `random()` comme avant et découvrirez comment la (mal)chance peut vous aider ! 🍀

  Vendredi 10h45 à 11h00 - Amphi E
• • Développement
  • Quicky

  Petit guide pratique des UUID

  Les UUID sont partout, utilisés souvent machinalement comme identifiant. Revenons un instant sur leurs origines et ce qu'ils garantissent vraiment — l'unicité globale sans coordination, pratique, mais pas toujours le meilleur choix comme clé d'unicité. On explore ensuite quand les employer (ou pas) dans des bases de données et des systèmes distribués, avant de comparer les différents générateurs créant des arbitrages concret entre confidentialité et performance.

  Vendredi 11h05 à 11h20 - Amphi E