Kako modelirati domenu u dobro dizajnirane klase?

Question

Accepted Answer

Dobro modeliranje klasa znači klase koje se mapiraju na stvarne domeniske koncepte, svaka sa **jednom jasnom odgovornošću**, povezane kroz iskrene **is-a/has-a** relacije, i ovisne o **apstrakcijama** na granicama. Nema formule, ali postoji ponovljiv proces. ## Praktičan 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 ``` ## Ponašanje slijedi podatke ```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); } } ``` ## Heuristike koje čuvaju hijerarhije zdrave | Heuristika | Razlog | |---|---| | Preferiraj kompoziciju; koristi nasljeđivanje samo za pravo is-a | Izbjegava fragile base class / LSP zamke | | Drži hijerarhije plitke (2–3 razine) | Duboka stabla sve vezuju | | Jedan razlog za promjenu po klasi (SRP) | Lokalizira promjenu | | Programiraj prema sučeljima na granicama | Testabilnost, zamjenjivost | | Čini value objekte nepromjenjivim | Uklanja cijelu klasu grešaka | ## Nedostatak Ne modeliraj *cijeli* svijet unaprijed. Počni mali sa konkretnim klasama; izvlači apstrakcije samo kada se pojavi stvarna varijacija (pravilo tri). Spekulativne hijerarhije loše stariju. ## Zašto je važno Model koji zrcali domenu čini kod samoobjašnjavajućim — novi inženjer čita `order.refund()` i razumije poslovanje, a ne samo sintaksu. Dobici se sabiraju: kohezivne, labavo povezane klase lokaliziraju promjenu, tako da nove značajke i ispravljanja grešaka dotičuju nekoliko datoteka umjesto da se šire kroz sustav.

Heuristika	Razlog
Preferiraj kompoziciju; koristi nasljeđivanje samo za pravo is-a	Izbjegava fragile base class / LSP zamke
Drži hijerarhije plitke (2–3 razine)	Duboka stabla sve vezuju
Jedan razlog za promjenu po klasi (SRP)	Lokalizira promjenu
Programiraj prema sučeljima na granicama	Testabilnost, zamjenjivost
Čini value objekte nepromjenjivim	Uklanja cijelu klasu grešaka