@AnyKtokolwiek: Własnie tak mi się wydawało, że tworzenie klasy dla każdego "Produktu", to lekka glupota i raczej tak to nie powinno wyglądać. Raczej faktycznie lepiej by było, lepiej zamodelować klase Product, tylko co było by dobrym wyjściem w przypadku, gdy dany produkt, nie potrzebowałby danego pola (tak czysto teoretycznie)?
I to jest ten obszar, że super-ładne OOP graniczy z prozą biznesową. W dwóch(?) kierunkach:
- jednak dziedziczenie, ale co najwyżej do niewielkiej ilości grup produktowych (i czy dziedziczenie naprawdę, czy kompozycja???). Zadanie domowe: część towaru, np napoje jest paczkowana po 6/8/12 - czym się różni od sprzedania np samochodu. Jak zamodelujesz?
- prozaiczne flagi isEnabled(String field), enum, whatever, niewiele to ma z uniwersyteckiej elegancji, ale to są zupełnie rzetelne realia klas "nośników danych"
- a może klasa ProductCategory prosi, aby ją wynaleźć?
@Skoq: Mysle, że gdzieś pasowałoby zrobić sprawdzenie, czy dany produkt nie jest zarezerwowany, przekazujac go i sprawdzajac, aby zlikwidować możliwość zarezerwowania, czegoś co jest zarezerwowane.
Zaczynasz sensownie zeznawać.
I tu idziemy do bardziej realnego projektu sklepu.
Okaże się, że Order to nie List<Product>
tylko List<OrderPosition>
a Position
MA/POSIADA (nie dziedziczy) Product
i przede wszystkim ilość.
i pewnie, że sklep jako "store", to nie List<Product>
tylko List<Stock>
a Stock
posiada (ma referencję do) Product
oraz ilość (być może też ilość zarezerwowaną)
(chyba za dużo powiedziałem i odebrałem smak własnego dochodzenia)
Pointa: prawda, że Hibernate wcale nie jest nam potrzebne do bardzo ciekawego rozwoju projektu?