Supermarktkasse

[showModal]

Hallo erstmal... :shock:

Ich habe von meinem Informatiklehrer kürzlich die Aufgabe bekommen, eine Supermarktkasse zu "programmieren".
Hierbei soll jedem einzelnen zu kaufenden Gegenstand demnach eine "Kennung" zugewiesen werden, welche die Kasse dann
im Prinzip über seinen Preis, die Art des Artikels, etc. informiert.

--> Es sollen also über jedes Produkt mehrere Informationen zur Verfügung stehen.

Anfangs schien mir die Aufgabe relativ leicht zu lösen, jedoch ist es jetzt mein Problem, den Artikeln ihre verschiedenen Informationen "zuzuteilen".


Es würde mich sehr freuen wenn ihr mir dort weiterhelfen könntet...

MfG, ShowModal ;)

[dominikkv]

Dann erstelle ein Record:

Delphi-Quellcode:

type
  TKennung = record
    Preis: Double;
    Bestand: Integer;
  end;

Wenn du uns noch ein paar Informationen gibst wie du die Artikel deklarierst können wir dir auch genauer helfen.

[Torpedo]

Sollen sich alle Informationen in der Kennung befinden, oder soll man durch die Kennung die Informationen aus einer Art Datenbank kriegen?

[Luckie]

Es läuft immer wieder auf das gleiche hinaus: Einzelne Objekte einer Klasse verwaltet in einer Kontainerklasse. Ein einzelnes Objekt wäre ein Artikel und der Container wäre die Kasse. Beispiel dazu hier: http://www.delphipraxis.net/internal...=760927#760927 und ausführliches Tutorial hier: http://www.michael-puff.de/Developer...er_Klassen.php

[Andreas L.]

Delphi-Quellcode:

uses ContNrs;

...

type
  TArtikel = class(TComponent)
  private
   fPreis: Double;
   fID: Integer; //Kennung
   //weitere Variablen hinzufügen....
  published //im published abschnitt ermöglichst du es, die Variablen als Eigenschaften auch außerhalb der KLasse zu benutzen
   property Preis: Double read fPreis write fPreis;
   property ID: Integer read fID write fID;
  end;

type
  TArtikelCollection = class(TComponent)
  private
   fIDCount: Integer; //speichert die anzahl der ids, jedesmal wenn du einen neuen Artikel erstellst, musst du diese erhöhen
   fArtikels: TObjectList;
  //... Den Rest schaffst du aber auch alleine, Vergiss nicht die ObjectList im Constructor zu erstellen ;-)

Denke, das sollte die erstmal helfen ;-)

[SirTwist]

Ich würd für den Preis eher "Currency" als Datentyp nehmen und nicht Double...

Gruß,
Michael

[Jelly]

Andreas Idee mit TObjectList ist an und für sich ganz gut, nur seine Umsetzung etwas unglücklich gewählt:

- TArtikel würde ich von TObject ableiten. Warum den ganzen Rotz von TComponent mit rumschleppen wenn's nicht gebraucht wird.
- Und die TArtikelCollection würd ich direkt von TObjectList ableiten. Das erspart dir die FIdCount Variable, und du kannst Collection spezifische Daten drin erfassen. TArtikelCollection ist ja nix anderes als die Kasse an sich, also könnte man da so Sachen wie Kassennummer, Kassierin usw. reinhauen. Damit hättest Du sämtliche Informationen in einem einzigen Objekt rumliegen, das intern in einer Liste die TArtikel aufgenommen hat.

Neben TObjectList gibts noch die TCollection und TCollectionItem Klassen. Damit lassen sich die ganzen Dinge auch direkt in einer Datei abspeichern, zumindest wenn man die TjsCollection nutzt.

[Luckie]

Zitat:

Zitat von Jelly

TArtikelCollection ist ja nix anderes als die Kasse an sich, also könnte man da so Sachen wie Kassennummer, Kassierin usw. reinhauen.

Und genau das würde ich nicht machen. TArtikelCollection entspricht ja eigentlich der Inventarliste, oder wie man das nennt, und die hat ja nichts mit den Kassen und den Kassierern zu tun. Kann sie ja auch gar nicht, weil man ja nicht weiß, an welcher Kasse der Artikel bezahlt wird.
Ich würde mit drei Klassen arbeten:
TArtikel - Beschreibt einen Artikel
TArtikkelCollection - Verwaltet die Artikel
TKasse - Verwaltet die Kasse und kennt die Artikelliste

Und im einzelenen Würde dass dann so aussehen:

TArtikel
- ID
- Preis Netto
- MwSt (weil unterschiedlich Lebensmittel, Luxusartikel)
- Bescheibung
- Warengruppe
- Hinzugefügt
- Verkaufsdatum
(- Verfallsdatum
- Einkäufer
- Großhändler
- ...
- ...)

TArtikellCollection
- Artikel: Liste(TArtikel)
- Hinzufügen
- Löschen (Verkauft oder entsorgt)
- Anzahl

TKasse
- ID
- Kassiererin
- Artikel bezahlen (Scannen, Preis eingeben)
- Gekaufte Artikel: Liste
- Hinzufügen
- Löschen (Stornieren)
- Anzahl
- Kassenabschluss (Summe aller Tageseinnahmen)

So würde ich es machen und das wwürde mir sinnvoll erscheinen.

Generelle Anmerkung: Es wird immer wieder gesagt, um richtig OOP programmieren zu können, müsste man abstrakt denken. Ich würde eher sagen, man muss die Realität verstehen und in einzelne sinnvolle Einheiten zerlegen können, dann ergibt sich die Klassenstruktur ganz von selber. Ich stelle mir das meist als Theaterstück oder so vor: Was für Darsteller / Akteure spielen mit, was machen sie und was müssen sie dazu können. Hier haben wir drei Akteure: Den Artikel, das Lager (Verkaufsraum) udn die Kasse. Was muss der Artikel können? Seine Eigenschaften verwalten. Was muss das Lager können? Eine List der Artikel führen ud zu dieser Liste Artikel hinzufügen und entfernen können. Was muss die Kasse können? Ihre Eigenschaften verwalten. Artikel einscannen und deren Preise aufsummieren können. Am Tagesende einen Kassenabschluss machen können.

Man könnte das Beispiel oben noch weiter zerlegen, in dem man sagt, dass TArtikel eine Elternklasse ist und die Warengruppen auch noch als Klassen vom Typ TArtikel sieht.

Es kommt auch darauf an, wie weit man gehen will oder soll.

[DGL-luke]

[OT]

Zitat:

Ich würde eher sagen, man muss die Realität verstehen und in einzelne sinnvolle Einheiten zerlegen können, dann ergibt sich die Klassenstruktur ganz von selber.

Ja, das (und insbesondere die Übersetzung in Programmcode) nennt man Abstraktion. :tongue:
[/OT]

[Luckie]

Ok, den Schritt der Modellierung und der Vereinfachung könnte man dann als Abstraktion sehen. ;)