Comment modéliser un domaine en classes bien conçues?

Question

Accepted Answer

Un bon modélisage de classe signifie des classes qui correspondent à de vrais concepts du domaine, chacune avec **une seule responsabilité claire**, liées par des relations honnêtes **is-a/has-a**, et dépendant d'**abstractions** aux frontières. Il n'y a pas de formule, mais il existe un processus répétable. ## Un processus pratique ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## Le comportement suit les données ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## Heuristiques pour maintenir des hiérarchies saines | Heuristique | Pourquoi | |---|---| | Préférer la composition ; n'utiliser l'héritage que pour de vrais is-a | Évite les pièges de la classe de base fragile / LSP | | Garder les hiérarchies peu profondes (2–3 niveaux) | Les arbres profonds couplent tout | | Une raison de changement par classe (SRP) | Localise le changement | | Programmer vers les interfaces aux coutures | Testabilité, interchangeabilité | | Rendre les objets de valeur immuables | Élimine une classe de bugs | ## Piège Ne modélisez pas le *monde entier* d'emblée. Commencez petit avec des classes concrètes ; extrayez les abstractions seulement quand une vraie variation apparaît (la règle de trois). Les hiérarchies spéculatives vieillissent mal. ## Pourquoi c'est important Un modèle qui reflète le domaine rend le code auto-explicite — un nouvel ingénieur lit `order.refund()` et comprend le métier, pas seulement la syntaxe. Le gain se compose : des classes cohésives et faiblement couplées localisent le changement, de sorte que les fonctionnalités et les corrections de bugs touchent peu de fichiers au lieu de se propager dans le système.

Heuristique	Pourquoi
Préférer la composition ; n'utiliser l'héritage que pour de vrais is-a	Évite les pièges de la classe de base fragile / LSP
Garder les hiérarchies peu profondes (2–3 niveaux)	Les arbres profonds couplent tout
Une raison de changement par classe (SRP)	Localise le changement
Programmer vers les interfaces aux coutures	Testabilité, interchangeabilité
Rendre les objets de valeur immuables	Élimine une classe de bugs