{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quel est le principal problème du pattern Singleton en .NET moderne avec Dependency Injection ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Singleton classique (instance statique) entre en conflit avec l'injection de dépendances car il crée un couplage fort et rend les tests difficiles. En .NET moderne, il est préférable d'utiliser le service lifetime 'Singleton' via DI (services.AddSingleton), qui offre les mêmes garanties d'instance unique tout en permettant l'injection, le mocking et la testabilité. Le Singleton statique contourne le conteneur DI et crée des dépendances cachées."}},{"@type":"Question","name":"Dans le pattern Factory Method, quelle est la différence entre Factory Method et Abstract Factory en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Factory Method définit une méthode virtuelle pour créer un seul type d'objet (ex: CreateLogger), permettant aux sous-classes de décider quelle classe concrète instancier. Abstract Factory définit une interface pour créer des familles d'objets liés (ex: IUIFactory avec CreateButton, CreateTextBox), permettant de créer plusieurs produits cohérents ensemble. Factory Method se concentre sur un seul produit avec polymorphisme, Abstract Factory gère plusieurs produits d'une même famille."}},{"@type":"Question","name":"Quel est l'avantage principal du pattern Builder en .NET pour créer des objets complexes avec de nombreux paramètres optionnels ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Builder évite les constructeurs télescopiques (multiples overloads avec différentes combinaisons de paramètres) en fournissant une interface fluide pour construire l'objet étape par étape. Il permet de créer des objets complexes avec des paramètres optionnels de manière lisible et maintenable, contrairement à des constructeurs avec 10+ paramètres. En C# moderne, les init properties et records peuvent remplacer Builder pour les cas simples, mais Builder reste utile pour la validation complexe ou la construction multi-étapes."}},{"@type":"Question","name":"Qu'est-ce que le principe de Single Responsibility (SRP) en SOLID et comment l'appliquer en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Le SRP stipule qu'une classe ne doit avoir qu'une seule raison de changer, c'est-à-dire une seule responsabilité. En .NET, cela signifie séparer les préoccupations : un Controller ne doit pas contenir de logique métier (utiliser des services), une classe ne doit pas gérer à la fois la persistance et la validation (séparer en Repository et Validator). Violer le SRP crée des classes difficiles à tester, maintenir et réutiliser. Par exemple, séparer UserService (logique métier) et UserRepository (accès données)."}},{"@type":"Question","name":"Qu'est-ce que le principe Open/Closed (OCP) en SOLID et comment l'implémenter avec des interfaces en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Le principe Open/Closed stipule qu'une classe doit être ouverte à l'extension mais fermée à la modification. En .NET, cela s'implémente via des interfaces et l'injection de dépendances : au lieu de modifier une classe existante pour ajouter un comportement, on crée une nouvelle implémentation de l'interface. Par exemple, pour ajouter un nouveau type de logger, créer une nouvelle classe implémentant ILogger plutôt que modifier la classe Logger existante. Cela réduit les régressions et améliore la maintenabilité."}},{"@type":"Question","name":"Qu'est-ce que le principe de Liskov Substitution (LSP) en SOLID et pourquoi est-il important pour le polymorphisme en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Le LSP stipule que les objets d'une classe dérivée doivent pouvoir remplacer les objets de la classe de base sans altérer le comportement du programme. En .NET, cela signifie que les sous-classes ne doivent pas violer les contrats de la classe de base (préconditions, postconditions, invariants). Par exemple, si Bird a une méthode Fly, créer une sous-classe Penguin qui lance une exception dans Fly viole le LSP. Préférer la composition ou des interfaces plus spécifiques (IFlyable) pour respecter le LSP."}},{"@type":"Question","name":"Qu'est-ce que le principe Interface Segregation (ISP) en SOLID et comment éviter les interfaces trop larges en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Le ISP stipule qu'aucun client ne doit être forcé de dépendre de méthodes qu'il n'utilise pas. En .NET, cela signifie préférer plusieurs petites interfaces spécifiques plutôt qu'une grosse interface générique. Par exemple, au lieu d'une interface IRepository avec 15 méthodes, créer IReadRepository, IWriteRepository, ISearchRepository. Cela permet aux classes d'implémenter uniquement ce dont elles ont besoin et améliore la testabilité en réduisant les dépendances inutiles."}},{"@type":"Question","name":"Qu'est-ce que le principe Dependency Inversion (DIP) en SOLID et comment l'implémenter avec ASP.NET Core DI ?","acceptedAnswer":{"@type":"Answer","text":"Le DIP stipule que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, tous deux doivent dépendre d'abstractions (interfaces). En ASP.NET Core, cela s'implémente en injectant des interfaces dans les constructeurs plutôt que des classes concrètes. Par exemple, injecter IEmailService plutôt que SmtpEmailService permet de changer l'implémentation sans modifier le code client. Le conteneur DI résout automatiquement les dépendances, et les tests peuvent facilement injecter des mocks."}},{"@type":"Question","name":"Quel est le but du pattern Strategy en .NET et quand l'utiliser plutôt qu'une série de if/else ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Strategy encapsule des algorithmes interchangeables dans des classes séparées implémentant une interface commune, permettant de sélectionner l'algorithme à l'exécution. En .NET, utiliser Strategy plutôt que if/else quand on a plusieurs algorithmes pour une même tâche (ex: différentes stratégies de pricing, de sorting, de compression). Cela respecte l'Open/Closed Principle en permettant d'ajouter de nouveaux algorithmes sans modifier le code existant. Combiner avec DI pour injecter la stratégie appropriée."}},{"@type":"Question","name":"Comment implémenter le pattern Strategy avec Dependency Injection en ASP.NET Core pour sélectionner une stratégie dynamiquement ?","acceptedAnswer":{"@type":"Answer","text":"En ASP.NET Core, enregistrer toutes les implémentations de l'interface de stratégie dans le conteneur DI, puis injecter IEnumerable dans le client. Le client peut ensuite sélectionner la bonne stratégie via une propriété discriminante (ex: strategy.Type). Alternativement, utiliser un factory pattern pour résoudre la stratégie à partir d'un paramètre. Pour les scénarios complexes, combiner avec le pattern Chain of Responsibility ou utiliser des services nommés via des dictionnaires injectés."}},{"@type":"Question","name":"Quel est le but du pattern Decorator en .NET et comment l'utiliser avec le middleware pipeline d'ASP.NET Core ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Decorator ajoute dynamiquement des responsabilités à un objet sans modifier son code, en l'enveloppant dans une classe décorateur. Le middleware pipeline d'ASP.NET Core est un exemple parfait : chaque middleware décore le suivant en ajoutant un comportement (logging, authentification, compression) tout en déléguant au suivant via next(). Cela respecte l'Open/Closed Principle et permet de composer des comportements de manière flexible. Utiliser également pour décorer des services via DI avec Scrutor."}},{"@type":"Question","name":"Comment implémenter un Decorator pour ajouter du logging à un service existant en .NET sans modifier le service original ?","acceptedAnswer":{"@type":"Answer","text":"Créer une classe décorateur qui implémente la même interface que le service, injecter le service original dans son constructeur et déléguer les appels tout en ajoutant du logging avant/après. En ASP.NET Core, enregistrer le décorateur dans DI avec services.Decorate() (via Scrutor) ou manuellement. Le décorateur respecte l'Open/Closed Principle en ajoutant du comportement sans toucher au code du service. Utile pour logging, caching, retry logic, validation."}},{"@type":"Question","name":"Quel est le rôle du pattern Repository en .NET et pourquoi l'utiliser avec Entity Framework Core ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Repository abstrait la couche d'accès aux données en fournissant une interface pour les opérations CRUD, isolant la logique métier de l'implémentation de persistance (EF Core). Cela permet de changer facilement l'ORM, de faciliter les tests avec des repositories en mémoire, et de centraliser les requêtes complexes. Bien qu'EF Core DbContext agisse déjà comme un Repository, créer une couche Repository explicite aide à respecter le Domain-Driven Design et à limiter l'exposition des détails EF Core (tracking, migrations) à la couche métier."}},{"@type":"Question","name":"Quand NE PAS utiliser le pattern Repository avec Entity Framework Core en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Ne pas utiliser Repository si l'application est simple et que DbContext est suffisant, car cela ajoute de la complexité inutile (over-engineering). DbContext implémente déjà Unit of Work et DbSet agit comme Repository. Pour les requêtes simples CRUD, exposer directement DbContext via services peut être plus pragmatique. Repository devient utile pour les applications complexes avec Domain-Driven Design, multiples sources de données, ou besoin d'abstraction forte. Éviter le Generic Repository anti-pattern qui expose IQueryable et fuite les détails EF Core."}},{"@type":"Question","name":"Quel est le rôle du pattern Unit of Work en .NET et comment Entity Framework Core DbContext l'implémente-t-il nativement ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Unit of Work maintient une liste de modifications (ajouts, suppressions, mises à jour) et les commit en une seule transaction. DbContext implémente ce pattern nativement : il track les changements via ChangeTracker et SaveChanges commit toutes les modifications dans une transaction automatique. Cela garantit la cohérence des données (toutes les modifications réussissent ou échouent ensemble). Pour des scénarios complexes multi-repository, créer une classe UnitOfWork explicite qui encapsule DbContext et expose plusieurs repositories peut améliorer la séparation des préoccupations."}},{"@type":"Question","name":"Comment combiner Repository et Unit of Work patterns en .NET pour gérer plusieurs repositories dans une même transaction ?","acceptedAnswer":{"@type":"Answer","text":"Créer une interface IUnitOfWork qui expose plusieurs propriétés repository (ex: Users, Orders, Products) et une méthode SaveChangesAsync. L'implémentation encapsule un DbContext partagé et passe ce DbContext à tous les repositories. Cela garantit que tous les repositories travaillent dans la même transaction. Enregistrer IUnitOfWork comme scoped dans DI pour avoir une instance par requête HTTP. Ce pattern est utile pour les opérations multi-entités complexes où plusieurs repositories doivent collaborer de manière cohérente."}},{"@type":"Question","name":"Quel est le problème du Generic Repository anti-pattern en .NET qui expose IQueryable ?","acceptedAnswer":{"@type":"Answer","text":"Exposer IQueryable dans un Generic Repository fuite les détails de l'implémentation EF Core à la couche métier, violant l'encapsulation et rendant impossible le changement d'ORM. IQueryable permet à la couche métier de construire des requêtes complexes (Include, Where, OrderBy) qui sont exécutées par EF Core, créant un couplage fort. Préférer des méthodes spécifiques dans les repositories (GetUserWithOrders, SearchActiveUsers) qui retournent des entités ou des collections matérialisées. Cela respecte le principe d'abstraction et facilite les tests."}},{"@type":"Question","name":"Comment implémenter le pattern Observer en .NET avec les événements C# et les delegates ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Observer en C# s'implémente nativement avec les événements et delegates. Définir un event dans la classe observable (ex: public event EventHandler OrderCreated), et les observateurs s'abonnent avec += (ex: orderService.OrderCreated += OnOrderCreated). Quand l'événement se produit, invoquer l'event (OrderCreated?.Invoke(this, eventArgs)). Pour des scénarios complexes, utiliser IObservable/IObserver (.NET Reactive Extensions) ou des message brokers (MediatR, MassTransit) pour découpler complètement publishers et subscribers."}},{"@type":"Question","name":"Quelle est la différence entre le pattern Adapter et le pattern Facade en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Adapter convertit l'interface d'une classe existante en une autre interface attendue par le client (ex: adapter une API externe pour correspondre à une interface locale). Facade fournit une interface simplifiée pour un sous-système complexe (ex: classe PaymentFacade qui masque la complexité de plusieurs APIs de paiement). Adapter se concentre sur la compatibilité d'interface, Facade sur la simplification. En .NET, utiliser Adapter pour intégrer des bibliothèques tierces, Facade pour simplifier l'utilisation de systèmes complexes dans la couche métier."}},{"@type":"Question","name":"Comment implémenter le pattern Command en .NET avec MediatR pour gérer les opérations métier ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Command encapsule une requête comme un objet, permettant de paramétrer les clients avec différentes requêtes, de les mettre en queue ou de les logger. MediatR implémente ce pattern : créer des classes de commande (ex: CreateOrderCommand) qui implémentent IRequest, et des handlers (CreateOrderCommandHandler) qui implémentent IRequestHandler. MediatR découple l'émetteur de la commande du handler, facilite le logging, la validation et le retry. Utiliser avec CQRS pour séparer les commandes (write) des queries (read)."}},{"@type":"Question","name":"Quel est l'avantage principal du pattern Template Method en .NET avec les classes abstraites et les méthodes virtuelles ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Template Method définit le squelette d'un algorithme dans une classe de base avec des méthodes abstraites ou virtuelles que les sous-classes overrident. Cela permet de réutiliser le flux commun (ex: connexion, traitement, fermeture) tout en permettant des variations spécifiques. En .NET, utiliser abstract pour les étapes obligatoires et virtual pour les étapes optionnelles. Exemple : classe abstraite ReportGenerator avec GenerateHeader (virtual), GenerateBody (abstract), GenerateFooter (virtual). Cela respecte le DRY principle et facilite l'ajout de nouveaux types de rapports."}},{"@type":"Question","name":"Comment implémenter le pattern Chain of Responsibility en .NET pour gérer le middleware pipeline d'ASP.NET Core ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Chain of Responsibility passe une requête le long d'une chaîne de handlers jusqu'à ce qu'un handler la traite. Le middleware pipeline ASP.NET Core implémente ce pattern : chaque middleware peut traiter la requête ou appeler next() pour passer au suivant. Créer un middleware custom en implémentant une classe avec InvokeAsync(HttpContext context, RequestDelegate next), enregistrer avec app.UseMiddleware(). Ordre important : les middlewares s'exécutent dans l'ordre d'enregistrement (ex: Authentication avant Authorization). Utiliser pour logging, validation, error handling."}},{"@type":"Question","name":"Quel est le rôle du pattern Options en ASP.NET Core et comment respecte-t-il les principes SOLID ?","acceptedAnswer":{"@type":"Answer","text":"Le pattern Options en ASP.NET Core permet d'injecter des configurations fortement typées via des classes POCO plutôt que d'utiliser IConfiguration directement. Enregistrer avec services.Configure(configuration.GetSection()), puis injecter IOptions, IOptionsSnapshot ou IOptionsMonitor. Cela respecte le Dependency Inversion Principle (dépend d'abstractions), le Single Responsibility Principle (classe de config séparée) et facilite les tests en permettant d'injecter des configurations mockées. Utiliser IOptionsSnapshot pour les configs scoped, IOptionsMonitor pour les changes à chaud."}},{"@type":"Question","name":"Comment combiner plusieurs design patterns (Repository, Unit of Work, CQRS, MediatR) dans une architecture Clean Architecture en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Dans Clean Architecture .NET : la couche Domain définit les entités, la couche Application contient les commandes/queries MediatR (CQRS) et les interfaces Repository (DIP), la couche Infrastructure implémente les repositories et Unit of Work avec EF Core. Les controllers ASP.NET Core dans la couche Presentation injectent IMediator et envoient des commandes/queries. Cela respecte tous les principes SOLID : SRP (séparation des couches), OCP (extension via nouveaux handlers), LSP (interfaces), ISP (petites interfaces), DIP (dépendances vers abstractions). Les tests unitaires mockent les repositories, les tests d'intégration utilisent un vrai DbContext."}}]}