Hvordan modellerer du et domene til godt utformede klasser?

Question

Accepted Answer

God klassemodelering betyr klasser som kartlegger til reelle domenekonsernt, hver med **ett klart ansvar**, relatert gjennom ærlige **is-a/has-a** relasjoner, og avhengig av **abstractions** ved grensene. Det finnes ingen formel, men det finnes en gjentagelig prosess. ## En praktisk prosess ```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 ``` ## Atferd følger data ```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); } } ``` ## Heuristikk som holder hierarkier sunne | Heuristikk | Hvorfor | |---|---| | Foretrekk komposisjon; bruk arv bare for ekte is-a | Unngår fragile base class / LSP feller | | Hold hierarkier grunne (2–3 nivåer) | Dype trær kobler alt sammen | | En grunn til endring per klasse (SRP) | Lokaliserer endring | | Programmer mot grensesnitt ved søm | Testbarhet, utskiftbarhet | | Gjør verdiobjekter uforanderlige | Eliminerer en klasse av feil | ## Fallgruve Ikke modeller hele verden på forhånd. Start lite med konkrete klasser; ekstrahér abstraksioner bare når ekte variasjon dukker opp (regelen om tre). Spekulative hierarkier eldes dårlig. ## Hvorfor det betyr noe En modell som speiler domenet gjør koden selvforklarende — en ny ingeniør leser `order.refund()` og forstår virksomheten, ikke bare syntaksen. Gevinsten stiger: kohesive, løst koblede klasser lokaliserer endring, slik at funksjoner og feilrettinger berører få filer i stedet for å bølge gjennom systemet.

Heuristikk	Hvorfor
Foretrekk komposisjon; bruk arv bare for ekte is-a	Unngår fragile base class / LSP feller
Hold hierarkier grunne (2–3 nivåer)	Dype trær kobler alt sammen
En grunn til endring per klasse (SRP)	Lokaliserer endring
Programmer mot grensesnitt ved søm	Testbarhet, utskiftbarhet
Gjør verdiobjekter uforanderlige	Eliminerer en klasse av feil