Modellieren eines Buchungssystems für Busfahrkarten

[kneitzel]

Ich will dir nicht auf den Schlips treten, aber ein richtiges Englisch wäre schon angebracht 😉
https://dict.leo.org/englisch-deutsch/vorname
https://dict.leo.org/englisch-deutsch/nachname

Das ist halt Englisch for Runaways (würde Otto Waalkes sagen).

Ansonsten zur Sache:
Aus meiner Sicht ist das wieder ein typischer Fall von zu hoher Komplexität. Wenn etwas so viel zu komplex wird, dann nutze Teile und Herrsche: Unterteile ein Problem so lange, bis die Teile für Dich beherrschbar sind!

Hier könnte man ganz konkret sagen: Schreibe z.B. kleine Methoden, die gezielt gewisse Dinge machen. Also so Dinge wie:
- gibt es einen Kunden schon?
- Kunden heraussuchen
- Kunden hinzufügen
- ...

Dann wird der Code hinterher extrem übersichtlich und gut lesbar. Und Du hast nur ganz kleine, einfache Methoden zu verstehen.

 

[xImJugo]

Das größte Problem, dass ich habe ist die Modellierung selbst von dem ganzen System. Normalerweise (ohne ArrayList als Basis zum Speichern) hat sich das Modellieren immer ziemlich ergeben, denn ich hätte einfach nur meine paar Klassen mit Konstruktoren und ihren methoden und Attributen und würde diese den entsprechenden Klassen einfach "weitergeben", aber da ich jetzt die verschiedenen Elemente auch in der Liste speichern muss, versteh ich plötzlich gar nicht mehr.

Für diese Aufgabe bzw Modellierung bräuchte ich doch eigentlich erst mal eine Bus Klasse (nur mit Busnummer), ein Ticket (Preis und Rechnungsnummer) und eine Station Klasse ( beschreibt Start und Zielbahnhof) und daraus ergibt sich dann eine neue Klasse Buslinie (dass auf den Bus, ticket und station zugreifen muss), aber wie mach ich das bitte mit den Arraylist und wo werden die gespeichert. Zum Bsp ich hab einen neuen Bus und der wird in seiner BusArrayList gespeichert. In Welcher Klasse steht dann diese Liste und wie gebe ich diese Liste mit den Eigenschaften von Bus weiter an die Buslinie Klassen? Ich will quasi die ArrayList der jeweiligen Klassen weitergeben, damit am Ende das ganze Booking System die gleichen Liste und Listenelemente benutzt.

Zur Zeit habe ich meine Befehle und Aufgaben mehr oder weniger gelöst. Ich hab halt eine Bulinie klasse (mit konstruktor, der busnummer, start und zielbahnhof, preis, währung) entgegenimmt, aber hier sieht man schonmal, dass es in dem Sinne keine gute Modellierung ist, da ich keinen Bus zum Bsp als eigene Klasse habe und eben keine BusListe. Meine 2. Klasse ist die Kundenklasse (konstruktor mit namen und erstellt automatisch eine neue Rechnungsnummer(immer um 1 erhöht), wenn ein neuer Kunde generiert wird. Hier habe ich es irgendwie geschafft, dass ich im Konstruktor die Liste mitgebe für meine 3. Klasse Buchung ( konstruktor nimmt name, busnummer entgegen und erzeugt im Konstruktor die Rechnungsnummer und einen neuen Kunden(mit dem kundenklasse konstruktor), der in die KundenArraylist gespeichert wird, welche sich auch in der BookingKlasse befindet. Meine letzte Klasse ist sozusagen eine Manager Klasse und heißt halt BookingSystem und hier drinn habe ich die BookingListe und BuslinienListe und alle Methoden der Aufgabe. Könnt ihr mir sagen, was ihr davon haltet und was ich ändern sollte?

 

[MoxxiManagarm]

Für diese Aufgabe bzw Modellierung bräuchte ich doch eigentlich erst mal eine Bus Klasse (nur mit Busnummer), ein Ticket (Preis und Rechnungsnummer) und eine Station Klasse ( beschreibt Start und Zielbahnhof) und daraus ergibt sich dann eine neue Klasse Buslinie (dass auf den Bus, ticket und station zugreifen muss), aber wie mach ich das bitte mit den Arraylist und wo werden die gespeichert.

Nein eben nicht, dass ist das, was mich bei deiner Aufgabe auch erst irritiert hat. Vergiss den Einleitungstext. Du kannst sicherlich Bus und Zielbahnhof Klassen erstellen, brauchen tust du sie aber nicht unbedingt. Ihre Identifier können auch einfach Attribute in referenzierenden Klassen sein.

Und ich habe das schon mehrmals gesagt, der Preis gehört in dieser Aufgabe nicht in das Ticket, der Preis gehört in die Route! Stell es dir am RL-Beispiel Flixbus vor. Das ist das Modell von dem wir reden. Der Kunde bucht eine Fahrt. Das Ticket bestimmt nicht den Preis, sondern die Verbindung bestimmt den Preis, welches lediglich durch das Ticket berechtigt wird. Die Verbindung ist eine Relation im Ticket, genauso wie der Kunde.

Du brauchst minimal wirklich nur diese 4 Klassen und die Attribute (wie auch immer du sie im Code benennst):
Verbindung(Busnummer, Start, Ziel, Preis, Währung)
Ticket(Rechnungsnummer, Relation Verbindung, Relation Kunde)
Kunde(Kundennummer, Vorname, Nachname)
Manager(Liste von Verbindungen, Liste von Tickets, optional Liste von Kunden)

Hier habe ich es irgendwie geschafft, dass ich im Konstruktor die Liste mitgebe

Du musst uns zuhören. Die Vorgehensweise haben wir auch schon erklärt. Das ist kein Hexenwerk sondern einfach nur ein statischer Wert.

public class Customer {
    private static int CUSTOMERNUMBER = 0;

    private int customernumber;
    private String firstname;
    private String lastname;

    public Customer(String firstname, String lastname) {
        this.customernumber = ++CUSTOMERNUMBER;
        this.firstname = firstname;
        this.lastname = lastname;
    }
}

 

[MoxxiManagarm]

Die Gleiche Vorgehensweise mit dem statischen Wert hast du auch bei den Tickets, d.h. Rechnungsnummer gibst du nicht mit in den Konstruktor, sondern nur die Relationen. Genau diese brauchst du also, bevor zu die Rechnung erstellen kannst.

Nimm dir erst die Relation Verbindung vor. Bei dem book-Befehl bekommst du die Busnummer. Suche die Verbindung mit dieser Busnummer. Falls es keine gibt ist das eine Fehlermeldung wert. Hast du die Verbindung suchst du den Kunden. Dafür iterierst du über die Kundenliste. Alternativ kannst du aber auch die Kunden über die Ticket-Liste scannen. Falls du keinen Kunden findest mit dem Namen, dann erstellst du einen. Dann nimmst du die Verbindung und den gefundenen bzw. erstellten Kunden und erstellst mit diesen beiden Objekten das Ticket. Fertig (abgesehen von Ausgaben und Fehlerhandling natürlich).

Rein theoretisch könntest du die Relationen auch auf der gegenüberliegenden Seite definieren, d.h. eine Verbindung könnte auch eine Liste von ihr zugeordneter Tickets führen und der Kunde könnte eine Liste von gekauften Tickets führen. Daher wird in einem ERM-Diagram nie angegeben auf welcher Seite die Relation gespeichert ist. Es wird jedoch empfohlen immer die Relation auf der Seite zu speichern, die nicht die Liste benötigt. Diese Modellierung ist vorallem für relationale Datenbanken geeignet.