Hvordan modellerer du et domæne ind i veldesignede klasser?

Question

Accepted Answer

God klassemodellering betyder klasser, der afspejler rigtige domænebegreber, hver med **ét klart ansvar**, forbundet gennem ærlige **is-a/has-a**-forhold, og afhængig af **abstraktion** ved grænserne. Der er ingen formel, men der er en gentagelig proces. ## En praktisk proces ```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 ``` ## Adfærd 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); } } ``` ## Heuristik, der holder hierarkier sunde | Heuristik | Hvorfor | |---|---| | Foretrække komposition; brug arv kun til ægte is-a | Undgå fragile base class / LSP-faldgruber | | Hold hierarkier lavvande (2–3 niveauer) | Dybe træer forbinder alt | | Én grund til ændring pr. klasse (SRP) | Lokaliserer ændring | | Programlæng mod grænseflader ved sømene | Testabilitet, udskiftelighed | | Gør værdigenstande uforanderlige | Eliminerer en klasse af fejl | ## Faldgruber Model ikke hele verden på forhånd. Start småt med konkrete klasser; uddrag abstraktioner kun når rigtig variation dukker op (reglen om tre). Spekulative hierarkier ældes dårligt. ## Hvorfor det betyder noget En model, der spejler domænet, gør koden selvforklarende — en ny ingeniør læser `order.refund()` og forstår virksomheden, ikke blot syntaksen. Udbyttet stiger: kohærent, løst koblede klasser lokaliserer ændring, så funktioner og fejlrettelser berører få filer i stedet for at bølge gennem systemet.

Heuristik	Hvorfor
Foretrække komposition; brug arv kun til ægte is-a	Undgå fragile base class / LSP-faldgruber
Hold hierarkier lavvande (2–3 niveauer)	Dybe træer forbinder alt
Én grund til ændring pr. klasse (SRP)	Lokaliserer ændring
Programlæng mod grænseflader ved sømene	Testabilitet, udskiftelighed
Gør værdigenstande uforanderlige	Eliminerer en klasse af fejl