dziedziczenie i alternatywa dla dziedziczenia w hibernate

Cześć, uczę się hibernata I w związku z tym mam pytanie, otóż mam taki przykladowy model:

class Order {

	private List<Product> products = new ArrayList<>();
	private Account account;

	//gettery, settery I reszta method pominięta
}

public abstract class Product {

	String name;
	BigDecimal price;

	//gettery, settery I reszta method pominięta
}

public class ExampleProduct extend Product {

	//tutaj wlasna logika dla każdego z produktu
}

I pytanie – czy taki model stosunkowo jest wporządku, aby każdy następny produkt dziedziczył po klasie “Product”? I czy jest jakas alternatywna opcja dla dziedziczenia w tym przypadku. Pierwotnie klasa “Product”, byla interfacem, jednak w momencie robienia encji z klasy “Order”, nie zezwalał mi informując, że “List<Product>” nie może być interfacem.

Pytanie brzmi po co robisz to dziedziczenie? Encje JPA nie powinny mieć jakiekolwiek logiki biznesowej, one są tylko modelem bazodanowym.

@scibi92: Gdyż chce w bazie danych przetrzymywać produkty, jak i zamówienie, które sklada się z tych produktów, a tworzenie listy dla ew. każdego innego skladnika, wydaje mi się złe.

prawywprawo napisał(a):

Cześć, uczę się hibernata I w związku z tym mam pytanie, otóż mam taki przykladowy model:

I pytanie – czy taki model stosunkowo jest wporządku, aby każdy następny produkt dziedziczył po klasie “Product”? I czy jest jakas alternatywna opcja dla dziedziczenia w tym przypadku.

Myślę, że nie tykaj Hibernate zanim gołej Javy nie oswoisz, z w miarę porządnymi wzorcami użycia itd... Kombinujesz strasznie.
JPA/Hibernate można użyć jeśli trzeba, ale na pewno nie jest to ostoja dobrych wzorców dla zielonych.
Taka kolejność nauki nie przybliża cię do 30k PLN/mc

Pierwotnie klasa “Product”, byla interfacem, jednak w momencie robienia encji z klasy “Order”, nie zezwalał mi informując, że “List<Product>” nie może być interfacem.

Iiii???
Masz przekonanie, ze rozumiesz w/w komunikat o błędzie, i wnioskujesz prawidłowo co do decyzji programistycznych?
Zetknąłeś się choć raz z Javadoc'em List ?

@AnyKtokolwiek: Nie wspominałem o 30tysiacach miesiecznie, raczej kierowałem się tu ku jakiejś radzie lub zwróceniu uwagi co można by zrobić, lub co przeczytac. Bo o dziwo, co sie jeszcze zdarza - ludzie się ucza ;)

Żeby nie tracić twojego czasu. NIGDY nie stosujemy dziedziczenia w Hibernate.

@Korges: Dzieki, zainspirowalem się tym, gdyż wiekszość poradników do hibernata korzysta z adnotacji @Inheritance.

prawywprawo napisał(a):

@Korges: Dzieki, zainspirowalem się tym, gdyż wiekszość poradników do hibernata korzysta z adnotacji @Inheritance.

Kiepskie (albo nie trafione w kontekst) poradniki plus małe ugruntowanie w postawach np dziedziczenia w plain Java - recepta na antynaukę.

Jakby to nie było Hibernate, tylko studencki "sklep" na List<ProductOrAnything> też byś tak dziedziczył?

@AnyKtokolwiek: Nie, raczej kierowałbym się ku interface, aczkolwiek wyglada na to, że nie wiem.

prawywprawo napisał(a):

@AnyKtokolwiek: Nie, raczej kierowałbym się ku interface, aczkolwiek wyglada na to, że nie wiem.

Obcykaj to, i szersze tematy w Javie SE, właśnie ze "studenckimi" bazami w List<>.
Na (elementy) EE przyjdzie ewentualnie pora jak nic w języku nie będzie cię zaskakiwać.
Sklep na sto towarów, to sto dziedziczeń (implementowanych interfejsów) ??? No chyba nie.

Po drugie, wielu jest z jakiś dziwnych kursów "zarażonymi" nadmierną skłonnością do dziedziczenia, jakoby to było istotą programowania obiektowego. A jest to tylko elementem, i to nie najważniejszym.
Zadaj sobie pytanie, pokombinuj: jak odwzorować zmienność zachowań towarów (stu, dwustu) inaczej (i czy w ogóle).
Po trzecie, być może krążysz w okolicy "eleganckiej obiektowej algorytmiki" np dziedziczenie interfejsów - ale klasy typu nośniki danych to nie jest "root of evil", one też mają prawo być realizowane (a przekraczają patrzenie interfejsowe czyli per-funkcjonaność).
.

W bieżącym kontekście czym się będzie różnić np. pralka od lodówki? Obydwa produkty beda miec cene, opis, zdjecie, ilosc sztuk. Ciebie nie powinno obchodzić czy ten produkt to akurat wcześniej wspomniana pralka czy np. karma dla psa. Oczywiście później mogą dojść jakieś kategorie produktów a wraz z nimi dodatkowe pola ale skupmy się na tym, że to dziedziczenie jest tutaj zbędne ;) Tak samo gdybyśmy pisali jakiś moduł odpowiedzialny za rezerwację czegoś. Czy ten moduł powinno obchodzić, że rezerwowany jest produkt X albo Y? :)

@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)?

@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.

Jasne, trzeba to sprawdzić, po to to jest :D Chodziło mi o to, że nie ma sensu tworzyć modułu np. fridge-reservation-module - do takiego modułu starczy nam, że będziemy przesyłać identyfikator produktu. Cały mój post był po to aby uświadomić Ci, że powinieneś dobrze zamodelować sobie co tam tworzysz i nie patrzeć takimi technikami jak dziedziczenie itp :)

@prawywprawo: generalnie dziedziczenie w JPA może mieć sens, np. masz tabelke z urządzeniami sieciowymi, a każde urzadzenie sieciowe ma osobne IP, więc robisz jakąs podstawową tabelkę network_device a do niej klucz obcy np. z router.
Najczęściej stosuje się chyba własnie dziedziczenie zamodelowane przez tabelę dla klasy bazowej i dodatkowe dla klas dziedziczących.

prawywprawo napisał(a):

@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?

@AnyKtokolwiek:

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?

Poszedlbym w stworzenie klasy Product i zaleznie od kategorii, tak jak w tym przypadku Samochod, umiescil przez kompozycje klase Product, w srodku Samochod, oczywiscie, tylko w sytuacji jesli klasa samochod potrzebowałaby faktycznie wlasnych pol - dobrze mysle?

Pointa: prawda, że Hibernate wcale nie jest nam potrzebne do bardzo ciekawego rozwoju projektu?

Oczywiscie, że nie, raczej było to forma treningu/zabawy, czasem przez wrzucenie rzeczy których nie znamy, można znalezc rzeczy których nie umiemy, bo wlasnie wtedy się one uwydatniaja. Poza tym zmusilo mnie to chociaz do podstatowego zapoznania sie z postgresem

@Skoq:
Dzieki wielkie za zwrocenie uwagi :D

prawywprawo napisał(a):

@AnyKtokolwiek:

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?

Poszedlbym w stworzenie klasy Product i zaleznie od kategorii, tak jak w tym przypadku Samochod, umiescil przez kompozycje klase Product, w srodku Samochod, oczywiscie, tylko w sytuacji jesli klasa samochod potrzebowałaby faktycznie wlasnych pol - dobrze mysle?

Moim zdaniem nie bardzo (ale to moze być pochodną "co mam przed oczami"). Konkretnie nie dewastować klasy "głównej" - w twoim pomyśle nie bardzo będzie jak wymyślić typ do List<what??>
Wśród moich wyobrażonych akceptowalnych implementacji

class Product {
   ICategorySpecyfic categoryInfo.
  ... 
}

class MulipleEmenetsBundleCategoryInfo implements ICategorySpecyfic  {
}

class CarsCategoryInfo implements ICategorySpecyfic  {
}

class DrinkskCategoryInfo implements ICategorySpecyfic  {
  int packing;
   // constructor,  getters, maybe setters;
}

class LiveAnimalsCategoryInfo implements ICategorySpecyfic  {
   String name;
   LocalDate vetExamination; 
   // constructor,  getters, maybe setters;
}

Może gryzł bym refleksją (generalnie lubię), a może ...

interface ICategorySpecyfic  {
   ... 
  String[] publishedProperties(); // { "name" "vetExamination"} ;
}

Ale to nie zasadzie narzucania, moje myślenie dawno jest bliższe "przemysłowemu" programowaniu niż elegancji "uniwersyteckiej".

Aha!!! I oczywiście opcja na nieśmiertelny Map<String,Object> (nazwa property, wartość)