Nietrywialna hierarchia dziedziczenia w modelu systemu sprzedaży biletów

0

Cześć,

Robię model systemu do sprzedaży biletów na połączenia lotnicze i muszę gdzieś stworzyć nietrywialną hierarchię dziedziczenia.
Mój pomysł żeby zrobić to w biletach, coś w tym stylu, ale tak żeby oczywiście to miało sens, bez zbędnego pompowania klas.
Może ma ktoś jakieś inne pomysły lub podpowiedziałby co zmienić lub dodać?
screenshot-20170328153328.png

0

Skad w ogóle taki pomysł? Jaki to niby ma sens? Od kiedy bilet jest rezerwacją? I co to jest nietrywialne dziedziczenie? Szczególnie że zwykle takie nietrywialne dziedziczenie oznacza błąd projektowy...

0

Na zajęcia muszę zrobić coś takiego. Dziedziczenie wystarczy żeby jedna z klas dziedziczyła jednocześnie po dwóch innych.Zamysł był taki, że wpierw jest rezerwacja a gdy zostanie opłacona tworzony jest bilet, więc ma wszystkie dane z rezerwacji + kilka dodatkowych. na razie nie wpadłem na inny pomysł, gdzie mógłbym zrobić takie dziedziczenie oczywiście nie licząc kont czy użytkowników,bo musimy znaleźć jakiś inny pomysł.

2

Zamysł był taki, że wpierw jest rezerwacja a gdy zostanie opłacona tworzony jest bilet, więc ma wszystkie dane z rezerwacji + kilka dodatkowych

Wtedy używa się kompozycji a nie dziedziczenia. W ogóle dziedziczenia używa się rzadko, chyba ze dziedziczysz po interfejsach. Jeśli wolno ci tak zrobić, to problemu nie powinno być bo takich sytuacji jest cała masa. Ot choćby jeden interfejs dla wszystkiego co można "kupić" czyli bilet na samolot, dodatkowy bagaż itd, i ten interfejs ma jakąś metodę getPrice() choćby. Następny interfejs na przykład dla rzeczy które można ubezpieczyć (np. bagaż) i on ma metodę w stylu getInsuranceRate() i getInsurancePrice() i voila. Biletów ubezpieczyć sie nie da, ale już bagaż jak najbardziej, a oba można kupić. Takich przykładów można mnożyć...

1 użytkowników online, w tym zalogowanych: 0, gości: 1