Hogyan lehet egy domaint jól megtervezett osztályokba modellezni?

Question

Accepted Answer

A jó osztálymodellezés azt jelenti, hogy az osztályok valós domain-fogalmakra térképeződnek, mindegyiknek **egy egyértelmű felelőssége** van, őszinte **is-a/has-a** kapcsolatokon keresztül kapcsolódnak egymáshoz, és **absztrakciókra** támaszkodnak a határok mentén. Nincs képlet rá, de létezik egy megismételhető folyamat. ## Egy gyakorlati folyamat ```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 ``` ## A viselkedés az adatokból fakad ```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); } } ``` ## Heurisztikák, amelyek az osztályhierarchrákat egészségesek tartják | Heurisztika | Miért | |---|---| | Az összetétel előnyben részesítése; az öröklést csak valódi is-a esetén használja | Elkerüli a törékenyen alaposztály / LSP csapdákat | | Sekély hierarchiák (2–3 szint) | A mély fák mindent összekapcsolnak | | Egy ok az osztály megváltoztatására (SRP) | A változást lokalizálja | | Interfészekre való programozás a csatlakozási pontoknál | Tesztelhetőség, cserélhetőség | | Value objektumok immutability-ja | Kiküszöböl egy féle hibát | ## Buktatók Ne modellezze az *egész* világot az elején. Kezdjen kicsivel, konkrét osztályokkal; csak akkor vontassa ki az absztrakciót, amikor valódi variáció jelenik meg (a három szabálya). A spekulatív hierarchiák gyorsan avulnak. ## Miért számít Az olyan modell, amely tükrözi a domaint, az önmagát megosztó kóddá teszi — egy új mérnök az `order.refund()` olvasásából megérti az üzletet, nem csak a szintaxist. A megtérülés összeadódik: a koherens, laza csatolású osztályok lokalizálják a változást, így az új funkciók és hibajavítások csak néhány fájlt érintenek ahelyett, hogy az egész rendszerre jellemzően terjedne.

Heurisztika	Miért
Az összetétel előnyben részesítése; az öröklést csak valódi is-a esetén használja	Elkerüli a törékenyen alaposztály / LSP csapdákat
Sekély hierarchiák (2–3 szint)	A mély fák mindent összekapcsolnak
Egy ok az osztály megváltoztatására (SRP)	A változást lokalizálja
Interfészekre való programozás a csatlakozási pontoknál	Tesztelhetőség, cserélhetőség
Value objektumok immutability-ja	Kiküszöböl egy féle hibát