Projekt w ramach programowanie obiektowego

Siemano, mam do naskrobania projekt. na podstawie takiego podziału muszę utworzyć klasy i interfejsy:

• wagon pasażerski, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon pocztowy, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon bagażowo-pocztowy
• wagon restauracyjny, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon towarowy podstawowy
• wagon towarowy ciężki
• wagon chłodniczy, będący rodzajem wagonu towarowego podstawowego, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon na materiały ciekłe, będący rodzajem wagonu towarowego podstawowego
• wagon na materiały gazowe, będący rodzajem wagonu towarowego podstawowego
• wagon na materiały wybuchowe, będący rodzajem wagonu towarowego ciężkiego
• wagon na materiały toksyczne, będący rodzajem wagonu towarowego ciężkiego
• wagon na ciekłe materiały toksyczne, który jest rodzajem wagonu towarowego ciężkiego, oraz posiada cechy wagonu na materiały ciekłe

jak polecacie to podzielić? ktoś chce w ramach treningu ze mną pokminić?

@3l3ctric_philip:

o sssso chodzi o ssssso chodzi

Daj prawdziwą treść zadania, a nie interpretację

Widzę tu potencjał na 3 klasy/interfejsy:

• wagon
• Lokomotywa
• Towar

Reszta to parametryzacja (np. Parametry oznaczające rodzaj przewożonego towaru - nazwę, stan skupienia itp. )

W sumie… bez kontekstu to nawet ciężko z tego zrobić jakieś OOP, bo co tu jest obiektowego? Po prostu dane. Mamy tutaj 3 rodzaje „Bytów” (przynajmniej ja dostrzegłem te 3) i to jeszcze można odróżnić. Ale to czy coś jest na materiały gazowe czy ciekłe nie wymaga kolejnej klasy (No chyba, że faktycznie zachowanie będzie inne - ale wtedy byśmy musieli rozważać konkretną grę i jej konkretne zasady)

No i jak chcesz takiej elastyczności, to tez można się zainteresować wzorcem Entity Component System. A jeśli nie, to po prostu warto skupiać się na kompozycji wszystkiego i unikać dziedziczenia.

Możesz też zajrzeć do źródeł istniejących gier (np. OpenTTD) i zobaczyć, jak tam to rozwiązali.
Np. tutaj masz klasę Train, która jak rozumiem reprezentuje wagon albo lokomotywę i zawiera połączenia do kolejnych wagonów w pociągu https://github.com/OpenTTD/OpenTTD/blob/master/src/train.h
I ma różne ciekawe właściwości

LukeJL napisał(a):

Widzę tu potencjał na 3 klasy/interfejsy:

• wagon
• Lokomotywa
• Towar

Więcej.

I to się ujawnia w realu. Co więcej, to jest w jak najlpeszym sensie nasz interface
Można puścić zestaw pasażerski w oparciu o lokomotywę X, ale nie w zimie, bo lokomotywa nie może dać znacznej mocy elektrycznej (na ogrzewanie), tylko na oświetlenie.
Historycznie zmieniało się całe konfiguracje na liniach w Polsce prowincjonalnej, żeby w zimie jeździły parowozy itd

https://pl.wikipedia.org/wiki/Sprz%C4%99g

Sądzę, ze wymyślający zadanie chciał uzyskać niemożliwość połączenia np pasażerskiego za towarowym

3l3ctric_philip napisał(a):

siemano, mam do naskrobania projekt. na podstawie takiego podziału muszę utworzyć klasy i interfejsy:
• wagon pasażerski, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon pocztowy, wymagający podłączenia do sieci elektrycznej lokomotywy
• wagon bagażowo-pocztowy

Jakiej mocy ten prąd ?

jak polecacie to podzielić? ktoś chce w ramach treningu ze mną pokminić?

Ja widzę INTERFEJSY "Prąd małej mocy" "prąd dużej mocy"
Wydzielić Scharfenberga
(skądinąd, zadanie o tym milczy)

Zadanie ma moim zdaniem wiele słabości, całe dywagacje o ładunku, jaki wagony niosą, nie mam najmniejszego pojęcia jak to wyrazić w OOP (choć mogę sobie wyobrażać, że dawca zadania "chciał dobrze")

@AnyKtokolwiek:

W finale, cały pociąg by był jakąs listą Linked List, wyobrażmy sobie eszelon na poligon, idąc od lokomotywy najpierw "wyższe" interfejsy (wagony z żołnierzami, ogrzewane), potem zwykłe towarowe, (na końcu czerwone lampy - na akumulatory czy dysponujemy prądem, nie wiem). Sprzęg pneumatyczny hamulca koniecznie.

Tak sie wczuwam, "co poeta miał na myśli".
Dywagacje o rodzaju ładunku w wagonie towarowym), to w innej przestzreni, raczej dziedziczenie klas, niż impelmentacja interfejsów - tyle że to robota bez sensu, bo nic z tego nie wynika

Z tego opisu trochę niewiele wynika. Np. czy "wagon towarowy ciężki" jest zwykłą klasą, czy abstrakcyjną?
Druga sprawa jest taka, że jak ci coś podpowiem to nie wiem, czy będzie dobrze ;)
Chodzi o to, że np. dla mnie to, czy wagon trzeba podłączyć do prądu czy nie to własność każdego możliwego wagonu (tj. interfejs/klasa Wagon, która byłaby na dole drzewa hierarchii posiada metodę electricSupplyConnectionRequired()). Strzelam, że zaraz wyjdzie, że należało mieć interfejs typu RequiresElectricSupplyConnection skoro to ćwiczenie na interfejsy i klasy.

Tak czy inaczej - wrzuć tutaj jak to według ciebie powinno wyglądać - wtedy postaram się odnieść i skomentuję jak to według mnie powinno wyglądać.

Imo to występują tutaj następujące sposoby połączeń:
elektryczne połączenie z lokomotywą
fizyczne połączenie z innym wagonem (nie ujęte w warunkach zadania, nie omawiam).

Wagony są łączone w łańcuch, więc nie zadziała połączenie gdzie tuż za lokomotywą będzie wagon bez instalacji elektrycznej.
Lokomotywa ma jedynie gniazdko do prądu, wagon ma zarówno gniazdko, jak i wtyczkę, więc pojawiają się następujące interface'y:
interface DostawcaPrądu, interface OdbiorcaPrądu

Teraz dziedziczenie, na samej górze jest klasa abstrakcyjna PojazdSzynowy, dziedzicza po niej zarówno Lokomotywa, jak i również abstrakcyjny wagon. Po abstrakcyjnym wagonie, dziedziczą wagony Pasażerski i PodstawowyTowarowy reszta hierarchii dziedziczy po tych wagonach.

Na koniec, wagony, które wymagają podłączenia do sieci elektrycznej dostają final class i 2 interface'y, lokomotywa dostaje jedynie interface DostawcaPrądu

Pozostają pytania co zrobić z wagonem restauracyjnym (może być albo pasażerskim, albo towarowym, ja bym go dał bezpośrednio pod PojazdSzynowy, ewentualnie wprowadził abstrakcyjny WagonSpecjalny. Druga pułapka, to:

wagon na ciekłe materiały toksyczne, który jest rodzajem wagonu towarowego ciężkiego,
oraz posiada cechy wagonu na materiały ciekłe

Co sugeruje wykorzystanie wielodziedziczenia (w Java niemożliwe), albo wprowadzenie interface'u TowaryCiekłe co jest możliwe, ale bez sensu.

Ogólnie, to zadanie czysto akademickie i pokazuje raczej jak szybko kończą się możliwości OOD/OOP.

wartek01 napisał(a):

Z tego opisu trochę niewiele wynika. Np. czy "wagon towarowy ciężki" jest zwykłą klasą, czy abstrakcyjną?
Druga sprawa jest taka, że jak ci coś podpowiem to nie wiem, czy będzie dobrze ;)
Chodzi o to, że np. dla mnie to, czy wagon trzeba podłączyć do prądu czy nie to własność każdego możliwego wagonu (tj. interfejs/klasa Wagon, która byłaby na dole drzewa hierarchii posiada metodę electricSupplyConnectionRequired()). Strzelam, że zaraz wyjdzie, że należało mieć interfejs typu RequiresElectricSupplyConnection skoro to ćwiczenie na interfejsy i klasy.

Tak czy inaczej - wrzuć tutaj jak to według ciebie powinno wyglądać - wtedy postaram się odnieść i skomentuję jak to według mnie powinno wyglądać.

Hej, no ja pojechałem tak: klasy abstrakcyjne: Wagon, Towarowy, Interfejs Wagon Elektryczny a reszta to klasy z poszczególnymi wagonami. Trochę strasznie to wygląda, bo wyszło 12 klas. a ciekłe materiały toksyczne rozegrałem tak, że dałem pola z dwóch klas (//pola wagonu ciężkiego z materiałami toksycznymi oraz wagonu podstawowego z materiałami ciekłymi), bo nie mogę dziedziczyć z dwóch klas, z interfejsami jakoś mi to nie wychodziło (potrzeba pól).

3l3ctric_philip napisał(a):

Hej, no ja pojechałem tak: klasy abstrakcyjne: Wagon, Towarowy, Interfejs Wagon Elektryczny a reszta to klasy z poszczególnymi wagonami. Trochę strasznie to wygląda, bo wyszło 12 klas. a ciekłe materiały toksyczne rozegrałem tak, że dałem pola z dwóch klas (//pola wagonu ciężkiego z materiałami toksycznymi oraz wagonu podstawowego z materiałami ciekłymi), bo nie mogę dziedziczyć z dwóch klas, z interfejsami jakoś mi to nie wychodziło (potrzeba pól).

No ja bym to zrobił trochę inaczej. Klas oczywiście będzie dużo, więc zrobiłbym to tak:

Interfejsy:
- ElectricConnectable
- LiquidMaterialContainer
- GasMaterialContainer
- ExplosiveMaterialContainer
- ToxicMaterialContainer

I teraz klasy:
x Wagon
  + PassengerWagon implements ElectricConnectable
  + PostalWagon implements ElectricConnectable
  + PostalLuggageWagon
  + RestaurantWagon implements ElectricConnectable
  x FreightWagon
    + BasicFreightWagon
      + CoolerWagon implements ElectricConnectable
      + LiquidMaterialWagon implements LiquidMaterialContainer
      + GasMaterialWagon implements GasMaterialContainer
    + HeavyFreightWagon
      + ExplosiveMaterialWagon implements ExplosiveMaterialContainer
      + ToxicMaterialWagon implements ToxicMaterialContainer
      + LiquidToxiMaterialWagon implements ToxicMaterialContainer, LiquidMaterialContaier

x - klasa abstrakcyjna
+ - klasa zwykła

Bierze się to z tego, że np. materiał przewożony może być jednocześnie toksyczny, wybuchowy, a także i gazowo-ciekły (tj. są mieszanki, które w zbiorniku są zarówno gazowe, jak i ciekłe).

3l3ctric_philip napisał(a):

Hej, no ja pojechałem tak: klasy abstrakcyjne: Wagon, Towarowy, Interfejs Wagon Elektryczny a reszta to klasy z poszczególnymi wagonami. Trochę strasznie to wygląda, bo wyszło 12 klas. a ciekłe materiały toksyczne rozegrałem tak, że dałem pola z dwóch klas (//pola wagonu ciężkiego z materiałami toksycznymi oraz wagonu podstawowego z materiałami ciekłymi), bo nie mogę dziedziczyć z dwóch klas, z interfejsami jakoś mi to nie wychodziło (potrzeba pól).

Ej, kolejarze, kolejarze (również ja)
O ile złącza (sprzęgi) pojazdu kolejowego, to jest interfejs, to zawartość (potencjalna) wagonu to kompozycja, wagon MA ZBIORNIK określonego typu, względnie MA ZDOLNOŚĆ określoność typu

piotrpo napisał(a):

.

Ogólnie, to zadanie czysto akademickie i pokazuje raczej jak szybko kończą się możliwości OOD/OOP.

Po pierwsze, znamy je w mglistym i korygowanym przekazie OP (pierwsza wersja była chyba o GUI)
a wiec i modelujemy, nie mając pełnego wyobrażanie o celach modelowania

O ile zamodelowanie wg sprzęgów jest dość jasne (pociąg zdolny/niezdolny do jazdy na szlaku), to wg zawartości wagonów najwyżej domniemane.

AnyKtokolwiek napisał(a):

LukeJL napisał(a):

Widzę tu potencjał na 3 klasy/interfejsy:

• wagon
• Lokomotywa
• Towar

Więcej.

I to się ujawnia w realu.

Zależy w jakiej szczegółowości to symulować. Ponieważ nie było kontekstu, to wyobraziłem sobie, że to ma być na potrzeby gry. A tu są przydatne uproszczenia.
Plus nierobienie zbyt wielu klas, tylko stawianie na kilka klas + rozmaite parametry do tweakowania, miałoby tę zaletę, że można by rozszerzyć taką grę bez potrzeby ruszania samego kodu źródłowego (jako ciekawostkę mogę podać GTA2, który przechowywał wszystkie rodzaje samochodów w pliku tekstowym i można było sobie tweakować np. robić samochód z większym przyśpieszeniem albo bardziej masywny. I wtedy ze zwykłego samochodu zrobić coś w rodzaju czołgu albo wyścigówki. Niemając nawet dostępu do kodu źródłowego)

Można puścić zestaw pasażerski w oparciu o lokomotywę X, ale nie w zimie, bo lokomotywa nie może dać znacznej mocy elektrycznej (na ogrzewanie), tylko na oświetlenie.

Oo, to ma sens, czemu przy niektórych jest wymóg elektrycznej lokomotywy.

LukeJL napisał(a):

AnyKtokolwiek napisał(a):

Można puścić zestaw pasażerski w oparciu o lokomotywę X, ale nie w zimie, bo lokomotywa nie może dać znacznej mocy elektrycznej (na ogrzewanie), tylko na oświetlenie.

Oo, to ma sens, czemu przy niektórych jest wymóg, że wymaga elektrycznej lokomotywy.

Nie wiem, jestem kibicem. Ale niektóre diesle, które moga ciągnąc wagony pasażerskie, maja zbyt małej mocy generator 400V / przetwornicę.
Mniemam, nie mam wiedzy, że generator główny jest zaprojektowany na wyższe napiecie (podobne do sieciowego 3000V)

Na pewno polskie lokomotywy projektowane w zamiarze towarowych, nie mają nadmiaru prądu na złączu. Czy mogą nie mieć wcale, nie wiem, CHYBA ostatnie czerwone lampy maja niezależność, akumulatory czy co.

Dawne wagony pasażerskie, na przykład, miały autonomiczne prądnice (i lokalne akumulatory), dośc to było charakterystyczne, zaczynało się kręcić jak wagon ruszał. Bo np parowozy nie dawały prądu wcale, albo co kot napłakał, a mocą mechaniczną zabieraną przez prądnice nikt się zbytnio nie martwił

czemu przy niektórych jest wymóg, że wymaga elektrycznej lokomotywy.

Przywołasz konkretny przykład? Jako kolejo-kibica mnie interesuje

no miałem na myśli np. to:

wagon restauracyjny, wymagający podłączenia do sieci elektrycznej lokomotywy
wagon pocztowy, wymagający podłączenia do sieci elektrycznej lokomotywy
wagon pasażerski, wymagający podłączenia do sieci elektrycznej lokomotywy

ale nie wiedziałem, o co chodzi. Myślałem, że ty wiesz, skoro napisałeś, że nie w zimie, bo ogrzewanie.
Ale w sumie to ma jakiś sens. Jeśli chcemy ogrzewać potrawy / mieć światło, to potrzebujemy prąd

A co jest celem projektu? Bez tego można mnożyć modele, które będą mniej lub bardziej przydatne do realizacji celu.

Relacje pomiędzy danymi które aplikacja ma ogarniać, to prawie nigdy nie jest relacja między elementami w języku programowania.

Jeśli chcesz zrobić zadanie faktycznie z programowania obiektowego, to polecam:

• interface List i implementacje ArrayList, VectorList, LinkedList, DoubleLinkedList
• interface Cache i implementacje MemoryCache, FileCache, RedisCache, DatabaseCache()
• interface Client i implementacje HttpClient, WebSocketClient, KafkaClient

To co Ty opisałeś - czyli jakieś wagony, i relacje między nimi - to z punktu widzenia kodu źródłowego nie ma znaczenia. Jeśli ja słyszę, że jakiś klient powiedziałby mi "Wagon towarowy jest też wagonem podstawowym", to niczego nie mogę być pewien tak bardzo jak tego że na pewno nie zrobiłbym WagonTowarowy implements WagonPodstawowy. Najpewniej te dane wylądowałyby w mapie lub drzewie, lub czymś takim.

Najpisz najpierw co ta aplikacja ma robić z tymi wagonami - przetwarzać je? symulować, wyświetlać, co ma z nimi zrobić? Potem należałoby zaimplementować taką aplikacje, i potem ewentualnie doszukiwać się relacji pomiędzy elementami w kodzie. Zacząłeś od złej strony.

@Riddle: Mądre słowa, ale podkopujesz autorytet wykładowcy, który to zadanie napisał :)

Myślę, że autor po prostu dostał do zrobienia projekt na zaliczenie jakiegoś kursu ze studiów, w ramach którego ma przećwiczyć używanie różnych elementów programowania obiektowego. Nie doszukiwałbym się tutaj nie wiadomo czego.

Wziąłem dzienniczek studentów konsolowy i zamieniłem w bazę danych w konsoli (jak midnight commander) a na przycisk generowała stronę www. Trochę wyobraźni. Zaczynam brać się za jave, czy pomogę - oczywiście, że tak.

johnny_Be_good napisał(a):

Wziąłem dzienniczek studentów konsolowy i zamieniłem w bazę danych w konsoli (jak midnight commander) a na przycisk generowała stronę www. Trochę wyobraźni. Zaczynam brać się za jave, czy pomogę - oczywiście, że tak.

Ale tylko C się liczy