Hur modellerar du en domän till väl-designade klasser?

Question

Accepted Answer

God klassmodellering betyder klasser som mappas till verkliga domänkoncept, var och en med **ett tydligt ansvar**, relaterade genom ärliga **is-a/has-a** relationer, och beroende på **abstraktioner** vid gränserna. Det finns ingen formel, men det finns en repeterbar process. ## En praktisk process ```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 ``` ## Beteende följer 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 som håller hierarkier friska | Heuristik | Varför | |---|---| | Föredra komposition; använd arv endast för sann is-a | Undviker bräcklig basklass / LSP-fällor | | Håll hierarkier grunda (2–3 nivåer) | Djupa träd kopplar allt | | En anledning till förändring per klass (SRP) | Lokaliserar förändring | | Programera till gränssnitt vid sömmar | Testabilitet, utbytbarhet | | Gör värdeobjekt oföränderliga | Eliminerar en klass av buggar | ## Fallgrop Modellera inte *hela* världen upp front. Börja litet med konkreta klasser; extrahera abstraktioner bara när verklig variation uppträder (regeln om tre). Spekulativa hierarkier åldras dåligt. ## Varför det är viktigt En modell som speglar domänen gör koden själv-förklarande — en ny ingenjör läser `order.refund()` och förstår affären, inte bara syntaxen. Vinsten förstärks: sammanhängande, löst kopplade klasser lokaliserar förändring, så funktioner och felrättningar berör få filer istället för att sprida sig genom systemet.

Heuristik	Varför
Föredra komposition; använd arv endast för sann is-a	Undviker bräcklig basklass / LSP-fällor
Håll hierarkier grunda (2–3 nivåer)	Djupa träd kopplar allt
En anledning till förändring per klass (SRP)	Lokaliserar förändring
Programera till gränssnitt vid sömmar	Testabilitet, utbytbarhet
Gör värdeobjekt oföränderliga	Eliminerar en klass av buggar