Kuinka mallinnit verkkotunnukseen hyvin suunnitellut luokat?

Question

Accepted Answer

Hyvä luokkamallinnus tarkoittaa luokkia, jotka vastaavat todellisia verkkotunnuksen käsitteitä, joista jokainen on **yksi selkeä vastuu**, liittyy toisiinsa rehellisten **is-a/has-a**-suhteiden kautta ja riippuu **abstraktioista** rajoilla. Kaavaa ei ole, mutta on toistettava prosessi. ## Käytännöllinen prosessi ```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 ``` ## Käyttäytyminen seuraa dataa ```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); } } ``` ## Heuristiikat, jotka pitävät hierarkiat terveellä | Heuristiikka | Miksi | |---|---| | Suosi komposition; käytä perintöä vain todelliseen is-a:han | Vältä fragile base class / LSP-ansoja | | Pidä hierarkiat matalia (2–3 tasoa) | Syvät puut sitovat kaiken | | Yksi muutoksen syy luokassa (SRP) | Paikantaa muutoksen | | Ohjelmoitu rajapintoihin saumoissa | Testaavuus, vaihdettavuus | | Tee value objects muuttumattomiksi | Eliminoi virheiden luokan | ## Sudenkuoppa Älä mallinna *koko* maailmaa etukäteen. Aloita pienillä konkreettisilla luokilla; poista abstraktiot vain silloin, kun ilmaantuu todellinen vaihtelu (kolmen sääntö). Spekulatiiviset hierarkiat ikääntyvät huonosti. ## Miksi sillä on merkitystä Malli, joka heijastaa verkkotunnusta, tekee koodista itsensä selittävän — uusi insinööri lukee `order.refund()` ja ymmärtää liiketoiminnan, ei vain syntaksia. Hyöty kertyy: koheesiiviset, löyhästi kytketyt luokat paikantavat muutoksen, joten ominaisuudet ja virheiden korjaukset koskettavat muutamia tiedostoja sen sijaan, että ne leviävät järjestelmän yli.

Heuristiikka	Miksi
Suosi komposition; käytä perintöä vain todelliseen is-a:han	Vältä fragile base class / LSP-ansoja
Pidä hierarkiat matalia (2–3 tasoa)	Syvät puut sitovat kaiken
Yksi muutoksen syy luokassa (SRP)	Paikantaa muutoksen
Ohjelmoitu rajapintoihin saumoissa	Testaavuus, vaihdettavuus
Tee value objects muuttumattomiksi	Eliminoi virheiden luokan