Übungsprogramm "Kinokarten"

[Aviator]

Zitat:

Zitat von EdAdvokat (Beitrag 1356242)

Noch eine kleine Frage habe ich zum Compilerhinweis besser charlnset zu verwenden bei der Abfrage der Editfelder (Key in...)

Und wie wäre die Frage?

CharInSet solltest du bei neueren Delphi Versionen verwenden. Müsste dann so aussehen:

Delphi-Quellcode:

if not CharInSet(Key, ['0'..'9']) then

[EdAdvokat]

Toll, Danke und es funktioniert sogar!!! Wieder ein kleines Problem gelöst. Ich finde es toll, dass das geballte Wissen so nieder regnet und wir es aufsaugen können (soll keinesfalls falsch aufgefasst werden!). Ich sitze hier in meinem Kämmerlein und grüble so nach und freue mich über jede neue Anregung und nehme sie auf, um daraufhin wieder neu zu starten (oft stundenlang, denn ich habe als Rentner durchaus Zeit oder nehme sie mir), was oft nicht ganz einfach ist, denn so gut bin ich noch nicht, doch es macht mir viel Spaß.
Nun stehe ich vor dem großen Problem von Luckie, der mir geraten hat die ganze Sache in eine Klasse zu verpacken. Richtig! aber wie fange ich das an? Erst einmal will ich die ganze Sache neu und ganz einfach schreiben. (OOP!!!) Oh je!. ist sicher richtig und zukunftsweisend. Doch es ist nicht einfach dieser Denkweise Raum zu geben.
Ich habe zurückliegend einem Projekt der Handelsschule in Berlin folgend ein OOP-Programm für mich geschrieben und will dieser Richtlinie nun folgen. Mal sehen ob was raus kommt. Jedenfalls habe ich in den letzten Tagen durch die Dialoge mit Euch einiges gelernt!!!

[EdAdvokat]

Hallo zusammen,
bevor ich in dieser Angelegenheit weiter fortfahre, möchte ich mich erst einmal vergewissern, ob ich auf dem richtigen Weg bin. Ich habe also versucht das bisherige Projekt Kinokarten (prozedural) nun in OOP zu schreiben. Ob es mir annähernd gelungen ist, bleibt abzuwarten und ich bitte daher um wohlwollende Kritik, damit ich meinen neuen Kurs neu justieren kann. Nach meinen Prüfungen dürfte all das was ich hier angeboten habe funktionieren. Auch die Sicherung der Eingabefelder(edits) habe ich etwas anders als bislang realisiert (NumberOnly, ReadOnly). All meine Prüfversuche, Blödsin in diese Felder zu kopieren klappt nicht.
Sollte ich als richtig liegen mit den vorangegangenen Hinweisen, könnte ich also noch den 3. Rang und die Begrenzung der jeweils zu verkaufenden Karten und auch eine Ermäßigung einbauen.

[Luckie]

Das kannst du alles private machen und verstecken. Öffentlich brauchst du nur drei Methoden:

Delphi-Quellcode:

BuyTickst(Anzahl: Integer; Rang: Integer);

Delphi-Quellcode:

RemainingTickts(Rang: Integer): Integer);

Delphi-Quellcode:

MaxTickets(Rang: Integer): Integer;

Mehr braucht der Nutzer deiner Klasse nicht wissen. Wie du das alles intern löst, interessiert nicht.

Aus Rang könnte man noch den Datentyp Enum machen. Ist aussagekräftiger.

[Luckie]

Nachtrag: Um die oben genannten öffentlichen Methoden würde ich die Klasse aufbauen. Einfach gucken, was brauche ich intern, um das umzusetzen. Welche Setter? Welche Getter? Wo und wie berechne ich was.

Man könnte aus der Karte auch ein Record machen, ist vielleicht noch besser. Ein Record mit folgenden Feldern: Rang (vom Typ Enum) und Preis.

Und für den Preis nimm besser den Datentyp Currency. Der ist genau für so was gemacht.

[EdAdvokat]

Hallo Luckie, ich kann wirklich nicht genau erkennen, welche meiner Methoden ich nur public lassen und die anderen privat deklarieren sollte. Könntest Du mir da anhand meiner Methoden einen konkreteren Tipp geben.(Welche meiner deklarieren Methoden meinst Du?) Was würde es schaden, wenn ich sie alle public lasse? Was hätte dass für Auswirkungen?
Grundsätzlich eine Frage: bin ich mit der OOP-Variante auf dem richtigen Weg?
Welchen Vorteil habe ich mit der Verwendung von enium?

[Luckie]

Wie schon gesagt. So ziemlich alle. Und ich würde von außen an die Sache ran fegen und nicht von innen. Welche Methoden braucht der Nutzer deiner Klasse?

Warum nicht alle public? Weil es zum einem übersichtlicher ist und er nicht in Versuchung kommt interne Methoden zu verwenden, deren Schnittstelle sich ändert. Bei den public Methoen kann er sich sicher sein, dass sich die Schnittstelle nicht ändert, zumindest, wenn sich auch der Ersteller der Klasse dran hält. Es kann ja sein, dass du die Klasse erweiterst und sich Parameter von Methoden ändern. Bei private Methoden kein Problem. Bei public Methoden dürftest du dir den Zorn des Nutzers zu ziehen.

Warum Enum? Was ist einfacher zu verstehen? Ein Integer, bei dem keiner weiß, was er bedeutet oder ein aussagekräftiger Enum Typ?

Delphi-Quellcode:

type
   TTicket = (Rang1, Rang2, Rang3);

Und wenn du es erweitern willst:

Delphi-Quellcode:

type
   TTicket = (Rang1, Rang2, Rang3, Loge, Parkett);

[Luckie]

Ein Problem ist auch die Verwaltung der noch verbleibenden Karten. Man könnte überlegen, ob man eine extra Klasse TTickt macht mit: Typ, Preis, MaxAnzahl und Rest oder so.
Und dann ein Array bzw. Objektliste für die Kartentypen.

Das ist schon nicht ganz banal, das elegant zu lösen. Das erfordert schon etwas überlegen. Mal sehen, wie ich morgen Zeit und Lust habe.

[Luckie]

Und wie man sieht, es lohnt sich etwas nachzudenken bevor man los programmiert. Bisher habe ich noch keine Zeile programmiert, aber man sieht, dass sich so langsam eine recht gute Lösung abzeichnet.

(Nur mal so als Anmerkung für die Anfänger, für die ja dieses Demoprogramm gedacht ist.)

[Jumpy]

Delphi-Quellcode:

BuyTickst(Anzahl: Integer; Rang: Integer);

Hallo,

hab mir dein Beispiel nicht angeguckt und reagiere einfach nur mal auf die Prozedure, die Lucky hier zitiert hat. Um das OOP-mäßig weiter auszubauen, könnte man vllt. wie folgt vorgehen:

Delphi-Quellcode:

BuyTickst(Warenkorb:TWarenkorb);

Sprich sowas wie ein Warenkorb-Objekt, das wiederum die zu kaufenden Tickets enthält. Ob das nun jedes Ticket einzeln ist (würde ab irgendeinem Punkt sicher Sinn machen, wenn es nummerierte Platztickets gibt) oder Listen aus Ticketanzahl pro Rang.