# 🔌 Interface Thinking — Penser contrats, pas détails **Interface Thinking** = raisonner sur **ce que fait** un module, pas **comment il le fait**. > **L'interface est le contrat. L'implémentation est un détail.** --- ## 🎯 Le principe Au lieu de : ```ts // Penser implémentation "J'ai besoin de PostgreSQL pour stocker les users"; ``` Pense : ```ts // Penser interface "J'ai besoin d'un Storage qui peut save() et load() des users"; ``` L'implémentation (PostgreSQL, MongoDB, fichiers...) devient interchangeable. > 💡 **L'invariant** : "Dépendre de l'interface, jamais de l'implémentation" --- ## 🧠 Pourquoi c'est crucial ? Sans interface thinking : - couplage fort aux détails - tests impossibles (dépendance DB/API) - changement = réécriture Avec interface thinking : - **découplage total** - **tests faciles** (mock l'interface) - **flexibilité** (swap d'implémentation) --- ## 📊 Architecture avec Interface Thinking --- ## 🔍 Exemple concret ### ❌ Sans Interface Thinking ```ts // Business logic couplée à l'implémentation class OrderService { async createOrder(data: OrderData) { // Dépendance directe à PostgreSQL const order = await db.query( "INSERT INTO orders (user_id, total) VALUES ($1, $2)", [data.userId, data.total] ); return order; } } ``` **Problèmes** : - Impossible de tester sans vraie DB - Impossible de changer de DB sans réécrire - Logic métier mélangée avec SQL --- ### ✅ Avec Interface Thinking ```ts // 1. Définir l'interface (le contrat) interface IOrderRepository { create(data: OrderData): Promise; findById(id: string): Promise; } // 2. Business logic dépend de l'INTERFACE class OrderService { constructor(private orderRepo: IOrderRepository) {} async createOrder(data: OrderData) { // Aucune idée si c'est PostgreSQL, Mongo, ou autre // On s'en fout : l'interface garantit le comportement return this.orderRepo.create(data); } } // 3. Implémentation concrète (détail) class PostgresOrderRepository implements IOrderRepository { async create(data: OrderData): Promise { return db.query("INSERT INTO orders..."); } async findById(id: string): Promise { return db.query("SELECT * FROM orders WHERE id = $1", [id]); } } // 4. Injection de l'implémentation const orderRepo = new PostgresOrderRepository(); const orderService = new OrderService(orderRepo); ``` **Bénéfices** : - ✅ Tests : `new OrderService(new MockOrderRepository())` - ✅ Swap DB : `new MongoOrderRepository()` → 0 impact sur OrderService - ✅ Séparation : logique métier ≠ détails SQL --- ; } class PaymentService { constructor(private provider: IPaymentProvider) {} async charge(amount: number) { return this.provider.charge(amount); } } class StripeProvider implements IPaymentProvider { async charge(amount: number) { const stripe = require('stripe')(API_KEY); return stripe.charges.create({ amount }); } }`, description: "Service dépend de l'interface, pas de Stripe" } }, { title: "Interface trop large (ISP violation)", badExample: { code: `interface IDatabase { connect(): void; disconnect(): void; query(sql: string): any; transaction(callback: Function): void; backup(): void; restore(file: string): void; optimize(): void; vacuum(): void; }`, description: "Interface monolithique avec 8 méthodes" }, problem: "Client qui veut juste query() doit implémenter 8 méthodes inutiles", solution: "Interfaces ségrégées (Interface Segregation Principle)", goodExample: { code: `interface IQueryable { query(sql: string): any; } interface ITransactional { transaction(callback: Function): void; } interface IMaintainable { backup(): void; restore(file: string): void; } // Client utilise SEULEMENT ce dont il a besoin class UserService { constructor(private db: IQueryable) {} }`, description: "Interfaces petites, ciblées, composables" } }, { title: "Interface qui fuit l'implémentation", badExample: { code: `interface IStorage { // ❌ Expose détails MongoDB getCollection(): MongoCollection; aggregate(pipeline: MongoPipeline[]): any; }`, description: "L'interface révèle que c'est MongoDB" }, problem: "Impossible de swap vers PostgreSQL sans changer l'interface = pas de découplage", solution: "Interface abstraite, indépendante de l'implémentation", goodExample: { code: `interface IStorage { // ✅ Abstrait, pas de détails MongoDB find(criteria: SearchCriteria): Promise; save(doc: Document): Promise; }`, description: "Peut être MongoDB, PostgreSQL, fichiers..." } } ]} /> --- ## 🧪 Principes d'une bonne interface ### 1. **Interface Segregation (ISP)** ```ts // ❌ Une grosse interface interface IUser { save(): void; delete(): void; sendEmail(): void; generateReport(): void; } // ✅ Interfaces ségrégées interface IPersistable { save(): void; delete(): void; } interface INotifiable { sendEmail(): void; } interface IReportable { generateReport(): void; } ``` --- ### 2. **Dependency Inversion (DIP)** ```ts // ❌ High-level dépend de low-level class OrderService { private db = new PostgresDB(); // Détail concret } // ✅ Les deux dépendent d'une abstraction interface IDatabase { /* ... */ } class OrderService { constructor(private db: IDatabase) {} // Abstraction } class PostgresDB implements IDatabase { /* ... */ } ``` --- ### 3. **Liskov Substitution (LSP)** ```ts // Toute implémentation doit être substituable function processOrder(repo: IOrderRepository) { // Doit marcher avec PostgresRepo, MongoRepo, MockRepo // Sans changer le comportement attendu } ``` --- (key)`, `set(key, value, ttl?)`, `delete(key)`", explanation: "API simple, universelle", }, { key: "Implémentations", value: "`MemoryCache` (Map), `RedisCache` (ioredis), `NullCache` (no-op pour tests)", explanation: "3 implémentations, même interface", }, { key: "Tests", value: "`new UserService(new MemoryCache())` → tests ultra-rapides", explanation: "Pas besoin de Redis pour tester la logique métier", }, { key: "Migration", value: "Passer de Memory à Redis = changer 1 ligne à l'injection", explanation: "0 impact sur les 50 services qui utilisent ICache", }, ], explanation: "Interface = point de découplage. Changer la techno ≠ réécrire l'app.", }, ]} /> --- --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant Interface Thinking, tu deviens capable de : - **Concevoir** des systèmes découplés par défaut - **Tester** sans dépendances externes (DB, API) - **Changer** de techno sans tout réécrire - **Composer** des modules indépendants Et surtout : Tu penses **comportement** avant **technologie**. L'interface, c'est ton langage de composition.