Le choix recopié partout
Le client veut envoyer une notification. Il ne devrait pas décider partout quelle classe construire.
Le même if, les mêmes new et la même erreur sont recopiés dans deux clients. Ajouter un canal oblige à retrouver chaque copie. La décision de création fuit dans du code qui devrait seulement exécuter son travail.
Notifications.java
La complexité n'a pas disparu
Le conditionnel existe encore, mais il possède désormais une adresse claire. Tous les clients passent par le même point de création.
Demander, créer, utiliser
Le client exprime un besoin
Il demande un objet capable d'envoyer une notification, sans nommer la classe concrète.La fabrique choisit
create(channel)centralise le conditionnel et lesnew.Le client utilise le contrat
La variable reste de typeNotificationSender. Le client appelle ensuitesend.
NotificationFactory.java
WelcomeController.java
| Rôle | Dans l'exemple | Responsabilité |
|---|---|---|
| Produit | NotificationSender | Définir ce que le client peut faire. |
| Produits concrets | EmailSender, SmsSender | Fournir les comportements concrets. |
| Fabrique | NotificationFactory | Choisir et construire le produit. |
| Client | WelcomeController | Demander, recevoir, puis utiliser. |
Ce que la fabrique ne fait pas
Une fabrique crée. Elle ne doit pas absorber le travail réalisé après la création.
À garder dans la fabrique
- • Choisir EmailSender ou SmsSender.
- • Construire l'objet concret.
- • Refuser explicitement un canal inconnu.
À laisser au workflow
- • Envoyer le message.
- • Gérer les nouvelles tentatives.
- • Décider quand notifier l'utilisateur.
Pourquoi retourner l'interface ?
Si
create retourne EmailSender, le client dépend encore d'une classe concrète. En retournant NotificationSender, le point de création peut changer sans changer l'usage.Quand sortir une fabrique
Bon cas
- • Le même choix de classe concrète revient dans plusieurs clients.
- • La classe dépend d'un type, d'un rôle ou d'une configuration.
- • Les clients doivent ignorer les détails de construction.
Mauvais cas
- • Un seul constructeur évident suffit.
- • Le choix n'existe qu'à un endroit et reste trivial.
- • La nouvelle classe ne ferait que déplacer une seule ligne.
| Question | Fabrique | Constructeur progressif |
|---|---|---|
| Problème central | Quel produit concret créer ? | Comment configurer progressivement un produit ? |
| Résultat | Une implémentation choisie derrière une interface. | Un objet assemblé à partir d'options nommées. |
| Coût | Un conditionnel central et une indirection. | Un objet temporaire et une API supplémentaire. |
Vérifiez vos réflexes
Vérifiez vos réflexes
Une réponse par question. La correction apparaît tout de suite.
Refactorez le choix
Centralisez les créations
Écrivez d'abord. Une IA externe pourra ensuite relire votre travail. Son retour peut être faux. Vérifiez-le avec la leçon.
Deux classes, WelcomeController et RetryJob, recopient le choix email/sms, construisent une classe concrète, puis appellent send.
1. Refactorez avec NotificationSender, EmailSender, SmsSender et NotificationFactory.create(String).
2. Le cas inconnu doit lever une IllegalArgumentException claire.
3. Refactorez les deux clients.
4. Montrez comment ajouter PushSender.
5. Expliquez en trois phrases ce qui a été centralisé, ce qui reste dans le client et un coût de la solution.
Votre réponse peut être un brouillon, mais les signatures et le trajet de l'appel doivent être cohérents.
Brouillon enregistré sur cet appareil.
À coller dans l'IA de votre choix.
Voir le prompt qui sera copié
Vous corrigez le travail d'un étudiant qui prépare une remédiation Java 17. Évaluez d'abord son raisonnement, ses invariants et la cohérence de son brouillon. Un code incomplet mais bien expliqué mérite un retour utile. Signalez précisément les erreurs sans inventer d'exigences hors sujet. Cette leçon porte sur Factory en Java. Vérifiez que la réponse retourne l'interface NotificationSender, centralise une seule fois le choix et les new, garde send et le workflow hors de la factory, et traite le canal inconnu explicitement. L'ajout de PushSender doit rester localisé. N'introduisez pas d'autre pattern. Demandez à l'étudiant d'expliquer où le choix existe encore et le coût du conditionnel central. Travail demandé: Deux classes, WelcomeController et RetryJob, recopient le choix email/sms, construisent une classe concrète, puis appellent send. 1. Refactorez avec NotificationSender, EmailSender, SmsSender et NotificationFactory.create(String). 2. Le cas inconnu doit lever une IllegalArgumentException claire. 3. Refactorez les deux clients. 4. Montrez comment ajouter PushSender. 5. Expliquez en trois phrases ce qui a été centralisé, ce qui reste dans le client et un coût de la solution. Votre réponse peut être un brouillon, mais les signatures et le trajet de l'appel doivent être cohérents. Commencez par poser au plus deux questions si une intention reste ambiguë. Donnez ensuite les points corrects, les problèmes précis et la plus petite prochaine étape. Ne fournissez une solution complète que si l'étudiant la demande explicitement. Réponse de l'étudiant: [aucune réponse collée]