Jak modelujesz domenę w dobrze zaprojektowanych klasach?

Question

Accepted Answer

Dobre modelowanie klas oznacza klasy, które mapują się na rzeczywiste koncepcje domeny, każdą z **jedną jasną odpowiedzialnością**, powiązane poprzez uczciwe relacje **is-a/has-a** oraz zależne od **abstrakcji** na granicach. Nie ma formuły, ale istnieje powtarzalny proces. ## Praktyczny 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 ``` ## Zachowanie podąża za danymi ```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); } } ``` ## Heurystyki, które utrzymują hierarchie w zdrowiu | Heurystyka | Dlaczego | |---|---| | Preferuj kompozycję; używaj dziedziczenia tylko dla prawdziwych is-a | Unika pułapek kruche baza klasy / LSP | | Utrzymuj hierarchie płytkie (2–3 poziomy) | Głębokie drzewa łączą wszystko | | Jeden powód do zmiany na klasę (SRP) | Lokalizuje zmianę | | Programuj do interfejsów na szwach | Testowalność, wymienialność | | Uczyń obiekty wartościowe niezmiennymi | Eliminuje klasę błędów | ## Pułapka Nie modeluj całego świata z góry. Zacznij małym od konkretnych klas; ekstrahuj abstrakcje tylko gdy pojawi się rzeczywista zmienność (reguła trzech). Spekulatywne hierarchie źle się starzeją. ## Dlaczego to ważne Model, który odzwierciedla domenę, sprawia, że kod jest samowyjaśniający się — nowy inżynier czyta `order.refund()` i rozumie biznes, a nie tylko składnię. Zysk się kumuluje: spójne, słabo powiązane klasy lokalizują zmianę, więc funkcje i poprawki błędów dotyczą kilku plików zamiast rozchodzić się po całym systemie.

Heurystyka	Dlaczego
Preferuj kompozycję; używaj dziedziczenia tylko dla prawdziwych is-a	Unika pułapek kruche baza klasy / LSP
Utrzymuj hierarchie płytkie (2–3 poziomy)	Głębokie drzewa łączą wszystko
Jeden powód do zmiany na klasę (SRP)	Lokalizuje zmianę
Programuj do interfejsów na szwach	Testowalność, wymienialność
Uczyń obiekty wartościowe niezmiennymi	Eliminuje klasę błędów