Come si modella un dominio in classi ben progettate?

Question

Accepted Answer

Una buona modellazione delle classi significa classi che corrispondono a concetti reali del dominio, ognuna con **una chiara responsabilità**, correlate attraverso relazioni **is-a/has-a** oneste, e dipendenti da **astrazioni** ai confini. Non c'è una formula, ma c'è un processo ripetibile. ## Un processo pratico ```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 ``` ## Il comportamento segue i dati ```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); } } ``` ## Euristiche che mantengono le gerarchie sane | Euristica | Perché | |---|---| | Preferisci la composizione; usa l'ereditarietà solo per veri is-a | Evita trappole della base class fragile / LSP | | Mantieni le gerarchie superficiali (2–3 livelli) | Gli alberi profondi accoppiano tutto | | Una ragione per cambiare per classe (SRP) | Localizza il cambiamento | | Programma verso interfacce ai confini | Testabilità, intercambiabilità | | Rendi gli oggetti valore immutabili | Elimina una classe di bug | ## Insidia Non modellare il *mondo* intero dall'inizio. Inizia in piccolo con classi concrete; estrai astrazioni solo quando apparisce una variazione reale (la regola del tre). Le gerarchie speculative invecchiano male. ## Perché è importante Un modello che rispecchia il dominio rende il codice auto-esplicativo — un nuovo ingegnere legge `order.refund()` e comprende il business, non solo la sintassi. Il vantaggio si accumula: classi coese, debolmente accoppiate localizzano il cambiamento, così le funzionalità e le correzioni di bug toccano pochi file invece di propagarsi in tutto il sistema.

Euristica	Perché
Preferisci la composizione; usa l'ereditarietà solo per veri is-a	Evita trappole della base class fragile / LSP
Mantieni le gerarchie superficiali (2–3 livelli)	Gli alberi profondi accoppiano tutto
Una ragione per cambiare per classe (SRP)	Localizza il cambiamento
Programma verso interfacce ai confini	Testabilità, intercambiabilità
Rendi gli oggetti valore immutabili	Elimina una classe di bug