En présentation SOLID, mes collègues ont interprété l'inversion de dépendance comme "une interface partout". Erreur classique, moi y compris à mes débuts. Une interface se justifie : frontière d'architecture, design pattern... Sinon, elle complexifie la lecture pour rien. Voici la checklist que j'enseigne pour trancher.

Tu écris encore des Builder().setX().build() en 2026 ? Ce pattern a plus de trente ans, et Kotlin l'a rendu obsolète enfin, pas exactement. Il est devenu invisible. Je te montre la manière moderne de construire tes objets complexes : le DSL type-safe. Et surtout, quand ne pas l'utiliser.

En tant que développeur Android, tu as un réflexe ancré depuis des années : tester ton app en conditions réelles avant de la livrer. Un APK sur un vrai device. Un backend de staging. Des données proches de la prod. Mais quand ton backend est une blockchain, comment tu fais ?

Tu as déjà travaillé sur un projet Android où tout le code était dans un seul module ?

Au début, ça semble raisonnable. Rapide à mettre en place, simple à comprendre. Puis le projet grossit. Les features s’accumulent. Et un jour tu te retrouves à modifier une ligne de code dans un coin obscur de l’app — et trois autres choses cassent ailleurs.