Le switch qui connaît tout
Le calcul change selon le rôle, mais le panier devrait toujours appeler la même opération.
Dans la première version, CartService connaît les noms métier et toutes les formules. Une nouvelle réduction agrandit le switch. Lire ou tester une règle oblige à traverser les autres branches.
CartService.java
Ce que Stratégie promet vraiment
Le pattern ne rend pas le calcul plus rapide et ne supprime pas la complexité. Il place chaque variante dans un objet séparé et garde le service stable.
Une règle par objet
Discounts.java
Le client choisit une stratégie
Il construit par exemple unStudentDiscountet le transmet au service.Le service garde le contrat
CartServicestocke unDiscountStrategy, pas une classe concrète.Le service délègue
checkout(100)appellestrategy.apply(100). AvecStudentDiscount, le résultat vaut80.
Ajouter VipDiscount ne demande aucune modification de CartService. La nouvelle formule vit dans la nouvelle classe.
Le choix existe encore
Quelqu'un doit toujours transformer le rôle en objet stratégie. Stratégie déplace cette sélection hors du service qui calcule.
CheckoutSetup.java
Un seul choix au moment de la construction est différent d'un switch recopié dans chaque calcul. Le premier assemble les objets. Le second mélange sélection et comportement.
| Question | Fabrique | Stratégie |
|---|---|---|
| Question dominante | Quel objet concret construire ? | Comment exécuter ce comportement ? |
| Responsabilité | Centraliser la création. | Isoler une variante et permettre la délégation. |
| Combinaison possible | Une fabrique peut choisir une stratégie. | Le service utilise ensuite la stratégie choisie. |
Quand déplacer les variantes
Bon cas
- • Plusieurs variantes réalisent la même opération.
- • Un if ou switch croît autour d'une politique.
- • Ajouter une règle ne doit pas modifier le service stable.
Mauvais cas
- • Deux cas triviaux resteront stables.
- • Les variantes n'ont aucun contrat commun clair.
- • L'interface accumulerait des opérations sans rapport.
Le prix de la séparation
Vous obtenez davantage de classes et la sélection doit toujours vivre quelque part. Ce coût devient intéressant quand les règles sont assez nombreuses ou assez différentes pour être comprises une par une.
Vérifiez vos réflexes
Vérifiez vos réflexes
Une réponse par question. La correction apparaît tout de suite.
Isolez les règles de livraison
Déplacez les formules
Écrivez d'abord. Une IA externe pourra ensuite relire votre travail. Son retour peut être faux. Vérifiez-le avec la leçon.
record Parcel(double weightKg, int distanceKm) {}
final class ShippingService {
double quote(Parcel parcel, String mode) {
return switch (mode) {
case "bike" -> 2 + parcel.distanceKm() * 0.25;
case "van" -> 4 + parcel.weightKg() * 1.20;
case "express" -> 10
+ parcel.weightKg() * 2
+ parcel.distanceKm() * 0.50;
default -> throw new IllegalArgumentException(mode);
};
}
}
Parcel sample = new Parcel(3, 10);
double price = new ShippingService().quote(sample, "express");
Chaque branche porte sa propre formule.
1. Créez une petite interface ShippingStrategy.
2. Écrivez BikeShipping, VanShipping et ExpressShipping.
3. ShippingService reçoit sa stratégie au constructeur et lui délègue quote.
4. Ajoutez TrainShipping avec la formule 6 + poids × 0,80 + distance × 0,20, sans modifier ShippingService.
5. Indiquez où le choix du mode doit encore avoir lieu.
6. Tracez l'appel express du colis fourni et vérifiez que le prix vaut 21.
7. Citez un cas simple où vous garderiez le switch.
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 Strategy en Java. Vérifiez qu'une même opération varie derrière une interface petite, qu'une classe porte chaque formule et que ShippingService délègue réellement à la stratégie reçue au constructeur. L'ajout de TrainShipping ne doit pas modifier le service. La réponse doit reconnaître que la sélection existe encore à la construction et citer le coût des classes supplémentaires. Ne transformez pas automatiquement cette sélection en un autre pattern.
Travail demandé:
record Parcel(double weightKg, int distanceKm) {}
final class ShippingService {
double quote(Parcel parcel, String mode) {
return switch (mode) {
case "bike" -> 2 + parcel.distanceKm() * 0.25;
case "van" -> 4 + parcel.weightKg() * 1.20;
case "express" -> 10
+ parcel.weightKg() * 2
+ parcel.distanceKm() * 0.50;
default -> throw new IllegalArgumentException(mode);
};
}
}
Parcel sample = new Parcel(3, 10);
double price = new ShippingService().quote(sample, "express");
Chaque branche porte sa propre formule.
1. Créez une petite interface ShippingStrategy.
2. Écrivez BikeShipping, VanShipping et ExpressShipping.
3. ShippingService reçoit sa stratégie au constructeur et lui délègue quote.
4. Ajoutez TrainShipping avec la formule 6 + poids × 0,80 + distance × 0,20, sans modifier ShippingService.
5. Indiquez où le choix du mode doit encore avoir lieu.
6. Tracez l'appel express du colis fourni et vérifiez que le prix vaut 21.
7. Citez un cas simple où vous garderiez le switch.
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]