Cum modelezi un domeniu în clase bine proiectate?

Question

Accepted Answer

Modelarea bună a claselor înseamnă clase care se mapează la concepte reale ale domeniului, fiecare cu **o responsabilitate clară**, legate prin relații cinstite **is-a/has-a** și dependente de **abstracții** la granițe. Nu există o formulă, dar există un proces repetabil. ## Un proces practic ```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 ``` ## Comportamentul urmează datele ```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); } } ``` ## Euristici care mențin ierarhiile sănătoase | Euristică | De ce | |---|---| | Preferă compoziția; folosește moștenirea doar pentru adevărata is-a | Evită capcanele clasei de bază fragilă / LSP | | Ține ierarhiile superficiale (2–3 niveluri) | Copacii adânci cuplează totul | | O singură rație pentru schimbare per clasă (SRP) | Localizează schimbarea | | Programează către interfețe la cusături | Testabilitate, interschimbabilitate | | Face obiectele de valoare imuabile | Elimină o clasă de bug-uri | ## Capcană Nu modela *întreaga* lume dinainte. Începe mic cu clase concrete; extrage abstracții doar când apare variație reală (regula celor trei). Ierarhiile speculative se îmbătrânesc rău. ## De ce conteaza Un model care oglinzește domeniul face codul auto-explicativ — un inginer nou citește `order.refund()` și înțelege afacerea, nu doar sintaxa. Beneficiul se compune: clase coezive și egal cuplate localizează schimbarea, așa că caracteristici și remedieri de bug-uri ating puține fișiere în loc să se răspândească pe tot sistemul.

Euristică	De ce
Preferă compoziția; folosește moștenirea doar pentru adevărata is-a	Evită capcanele clasei de bază fragilă / LSP
Ține ierarhiile superficiale (2–3 niveluri)	Copacii adânci cuplează totul
O singură rație pentru schimbare per clasă (SRP)	Localizează schimbarea
Programează către interfețe la cusături	Testabilitate, interschimbabilitate
Face obiectele de valoare imuabile	Elimină o clasă de bug-uri