Berechnungsergebnise verschiedener Klassen zusammenführen

[DeddyH]

Das jetzt lang und breit zu erklären fehlt mir die Zeit, aber stell Dir die Objektliste als ein "klassenglobales Feld" vor, das für die Basisklasse sowie alle abgeleiteten Klassen gilt. Näheres dazu findest Du hier: http://docwiki.embarcadero.com/RADSt...lassenmethoden

[EdAdvokat]

Das ist verdammt harte Kost. Ich habe noch immer nicht verstanden, welche Vorteile mir die Arbeit mit Klassenmethoden gegenüber der bislang praktizierten OOP bringt, also was ist der Vorteil dieser Weiterentwicklung für den Programmierer mal unabhängig von Objectlisten usw.?
Was kann ich besser mit class function xyz oder class procedure xyz gegenüber function xyz oder procedure xyz bei der Programmierung grundsätzlich erreichen? Ich verstehe durchaus, dass es nicht einfach ist, soetwas hier zu erklären, doch mit entsprechender Literatur sieht es weniger gut aus.
Ich habe mich bereits an Marco Cantu in engl. herangemacht, doch das ist verdammt schwer für mich alten Zausel. Es ist ja nur für mich als Hobbyist.

[freimatz]

Hallo,
soweit ich das beurteilen kann, meine ich dass Du Klassenmethoden hier nicht nehmen sollst. Eine TKarte repräsentiert eine einzelne Karte und sollte von anderen Karten nichts wissen.
Du kannst das wie Du ja auch schon hast in das formular tun, das aber nur wie bei deinem Beispiel wenn es ganz einfach ist. Sonst schlage ich eine separate Klasse TKarten vor, die die einzelnen Karten enthält und auch die Aufrechnung vornimmt. Ob dann da intern eine ObjectListe oder wie auch immer drin ist, sollte von außen nicht mehr sichtbar sein.

Nochmals zu Klassenmethoden: ich halte die für fast so schlimm wie globale Methoden. Man sollte diese nur einsetzen wenn es unbedingt nötig ist.

PS.: Der Trend geht übrigens wieder weg von OOP

[EdAdvokat]

Zitat:

Zitat von freimatz (Beitrag 1400380)

Du kannst das wie Du ja auch schon hast in das formular tun, das aber nur wie bei deinem Beispiel wenn es ganz einfach ist. Sonst schlage ich eine separate Klasse TKarten vor, die die einzelnen Karten enthält und auch die Aufrechnung vornimmt. Ob dann da intern eine ObjectListe oder wie auch immer drin ist, sollte von außen nicht mehr sichtbar sein.

Meinst Du ggf. folgende Lösung, die ich vormals bereits vorgenommen habe: https://www.delphipraxis.net/191102-...inokarten.html
bitte dort die letzte Variante ansehen.
Mit den jetzigen theoretischen Versuchen wollte ich dieses alte Projekt ggf. so neu programmieren, dass ich für jeden Rang oder Loge (Kinokarten) eine gesonderte class bilde und so das Projekt neu erstelle.
Das ist wohl nicht ganz so einfach wie ich dachte.
Wohin geht denn nun der Trend, wenn weg von OOP?

[DeddyH]

Zitat:

Zitat von freimatz (Beitrag 1400380)

Sonst schlage ich eine separate Klasse TKarten vor, die die einzelnen Karten enthält und auch die Aufrechnung vornimmt. Ob dann da intern eine ObjectListe oder wie auch immer drin ist, sollte von außen nicht mehr sichtbar sein.

Und der Mehrwert gegenüber der Klasseneigenschaft liegt genau worin?

[Jumpy]

Es scheint ja um Kinokarten / Kinokasse oder sowas zu gehen.

Wäre da nicht formal folgende Struktur angebracht (sinnvoller weiß ich jetzt nicht).

Eine Warenkorbklasse mit Liste von Warenkorbpositionen und einer Funktion Gesamtsumme, die über die Positionen in der Liste iterriert und summiert.
Eine Warenkorbposition-Klasse mit einem Variable für Anzahl und eine für die Kartenklasse und der Funktion Positionssumme (Anz x Kartenpreis).

Bleibt die Frage, was ist eine Kartenklasse. Da könnte man mit einer Basisklasse und entsprechenden Ableitungen für die einzelnen Kartentypen (Loge/Parkett usw.) arbeiten und/oder man könnte auch das Dekorator-Pattern anwenden, da man zu der Karte ggf. noch was dazurechnen muss: 3D-Zuschlag, Überlängen-Zuschlag, usw.

[EdAdvokat]

Zitat:

Zitat von Jumpy (Beitrag 1400429)

Es scheint ja um Kinokarten / Kinokasse oder sowas zu gehen.

Wäre da nicht formal folgende Struktur angebracht (sinnvoller weiß ich jetzt nicht).

Eine Warenkorbklasse mit Liste von Warenkorbpositionen und einer Funktion Gesamtsumme, die über die Positionen in der Liste iterriert und summiert.
Eine Warenkorbposition-Klasse mit einem Variable für Anzahl und eine für die Kartenklasse und der Funktion Positionssumme (Anz x Kartenpreis).

Bleibt die Frage, was ist eine Kartenklasse. Da könnte man mit einer Basisklasse und entsprechenden Ableitungen für die einzelnen Kartentypen (Loge/Parkett usw.) arbeiten und/oder man könnte auch das Dekorator-Pattern anwenden, da man zu der Karte ggf. noch was dazurechnen muss: 3D-Zuschlag, Überlängen-Zuschlag, usw.

Ja, ich habe vor einiger Zeit mal so ein Übungsprogramm erstellt und wollte es jetzt anders nochmals gestalten mit Klassen für den Rang/Loge.
Ist das Du als Warenkorbklasse bezeichnest folgendes:

Delphi-Quellcode:

type
  TKinokarten = class(TObject)
   private
     const MWSt = 0.19; //gesetzliche MWSt
           Preisliste : TRangPreis =(15, 13,10);
           Ermaessigung: array [boolean] of Currency = (0,1);
       function GetVerkaufteKarten(index: TRang; ermaessigt: boolean):Currency;
     var
       fFreiePlVorgabe: TRangNr;
       FKarten: TRangNr;
       fgekaufteKarten: TRangNr;
       ffreiePlR: TRangNr;
       fPreisR : TRangPreis;

       function GetgekaufteKarten(index: TRang): integer;
       function GetfreiePlR(index: TRang): integer;
       function GetZwSu: Currency;
       function GetMWSteuer:Currency;
       function GetPreis: Currency;
       function GetVorgabePlaetze(index: TRang): integer;

     public
       constructor create(const VorgabePl1, VorgabePl2, VorgabePl3 : integer);

       procedure init;
       function setAnzKarten(index: TRang; Value: integer): boolean;
       procedure setgekKarten(index: TRang; Value: integer);
       procedure BerechnePreisRang(index: TRang; aErmaessigt: boolean);
       procedure BerechnegekKarten;
       procedure BerechnefreiePlRang;
       function getVorgabeGesamt: integer;
       function freiePlGesamt: integer;
       function gekaufteKartenGesamt : integer;

       property VorgabePlaetze[index: TRang]: integer read GetVorgabePlaetze;
       property gekaufteKarten[index: Trang]: integer read GetgekaufteKarten;
       property freiePlR[index: TRang]: integer read GetfreiePlR;

       property ZwSu: Currency read getZwSu;
       property MWSteuer: Currency read getMWSteuer;
       property Preis: Currency read getPreis;
       property VerkaufteKarten[index: TRang; Ermaessigt: boolean] : Currency read GetVerkaufteKarten;
     end;

Dies habe ich vormals so in Form einener Klasse erstellt. Nun wollte ich zunächst probieren ob eine Lösung mit abgeleiteten Klassen für die Ränge eine tragfähige Lösung wäre. Dabei ergibt sich das Problem der Zusammenführung von Werten aus den verschiedenen abgeleiteten Klassen, um beispielsweise die bisherigen Einnahmen oder die verkauften Karten für die Ränge zusammenzurechnen. Allein dieses Problem hat mich veranlasst die Frage hier zu stellen.

[Jumpy]

Deswegen ja mein skizzierter Ansatz mit verschiedenen Klassen und nicht alles in eine Klasse zu packen. Ist ja auch als Übung vllt. interessanter zu sehen, wie die Klassen ineinander greifen. Das Ganze kann ja beliebig komplex werden:
- Mehrere Kinosäle, mit unterschiedlicher Zusammensetzung an Loge- und Parket-Karten.
- Es müssen die Kartenstände (verkaufte Karten vs. freie Karten) für die einzelnen Säle für die einzelnen Tage oder besser Vorstellungen nachgehalten werden.
- Filme könnte einen Klasse sein, mit Eigenschaften, wie 3D, Überlänge usw. und Sälen/oder Vorstellungen zugeordnet werden.

Ich denke man sieht, das hier viele unterschiedliche Klassen am Werk sein sollten.