Thursday, November 6, 2025
Arrêtons de créer des interfaces « au cas où »
Dans le monde .NET, on nous a tous dit un jour :
Abstrais tout derrière une interface.
Résultat :
IOrderService, IEmailService, IPaymentService… et des dizaines de fichiers inutiles. 😅▸ Le problème
Souvent, chaque interface a une seule implémentation. On fait donc ça 👇
public interface IOrderService { void PlaceOrder(); }
public class OrderService : IOrderService { ... }
➡️ Et on croit avoir « découplé » notre code. Mais en réalité, on a juste dupliqué la complexité.
▸ Pourquoi c'est un anti-pattern
Une interface sans alternative ≠ abstraction. Tu n'as rien gagné, juste du bruit.
Les tests n'ont pas besoin d'interfaces. On peut tester une classe concrète, injecter un
Func<>, ou dériver un type pour substituer le comportement.Les interfaces ne suppriment pas le couplage. Tu es juste couplé… à ton contrat.
La DI (Dependency Injection) n'exige PAS les interfaces. Le conteneur Microsoft sait injecter des classes concrètes.
▸ Quand une interface a du sens
Quand tu as plusieurs implémentations (ex. SendGrid / SES / SMTP).
Quand tu définis une frontière claire entre modules ou domaines.
Quand tu veux simplifier une API publique.
▸ Moralité
Créer une interface « au cas où » revient à payer de la dette de complexité tout de suite… pour un scénario hypothétique qui n'arrivera peut-être jamais.
Abstract everything, and you're left with a bunch of nothing.Derek Comartin
▸ Et toi ?
Tu es dans le camp 🔥 « une interface par service » ou plutôt 🧠 « interfaces quand c'est utile » ?
Dis-moi en commentaire 👇
Does this resonate with your team?
Let's talk about how Atypical Consulting can help you move forward.
Contact me