Ideen für Objektaufbau

[sprudel]

Guten Abend,

ich schreibe derzeit an einem kleinen Kassensystem, habe aber einige Probleme mit dem Aufbau der Objekte (mit dem Konzept hierbei)..

Was ich möchte:
Eine zentrale Transaktion, die sich zusammensetzt aus Angebot, Verkaufsvorgang, aber auch Retouren ermöglicht
Produkte.. hier habe ich derzeit die Trennung in ProductDefinition und ProductObject... ich weiß nicht, ob das so sinnvoll ist. Hierbei ist die ProductDefinition jeweils die Definition von einer Produktklasse, und das ProductObject erfasst die Abweichungen, zum Beispiel auch den Verkaufspreis, eventuelle Artikeltexte (wie Kratzer, etc).....

Bei dem ganzen bin ich mir einfach nicht sicher, wie ich das am besten strukturiere.. habt ihr da Ideen, was sich am besten für ein Aufbau eignet? Bin über jede konstruktive Kritik sehr dankbar.

Beste Grüße
Chris

[problembär]

Die Trennung in ProductDefinition und ProductObject kommt mir komisch vor. Ich würde eher eine einzige Klasse "Product" machen. Z.B.:

Code: Alles auswählen

#!/usr/bin/env python
# coding: iso-8859-1

class Product(object):

    def __init__(self, price):
        self.price = price

singleproduct = Product(price = 50)

Wenn Du dann noch eine andere, ähnliche Klasse brauchst, die sich aber in Einzelheiten unterscheidet, könntest Du sie von "Product" erben lassen.

[sprudel]

Das mit dem Vererben klingt ja schonmal spannend... aber wie würde ich das Elixir beibringen? Oder soll ich einfach die eingebuchten Produkte wie sie eben sind, bei der Lagereinbuchung erstellen, und ab dann eben verändern können? Also ein Product pro real existierendem Produkt?

[problembär]

Das mit dem Vererben klingt ja schonmal spannend... aber wie würde ich das Elixir beibringen?

Oder soll ich einfach die eingebuchten Produkte wie sie eben sind, bei der Lagereinbuchung erstellen, und ab dann eben verändern können? Also ein Product pro real existierendem Produkt?

Das würde sich wohl anbieten. Du erzeugst soviele Objekte von Product wie es Produkte gibt. Dafür brauchst Du aber nur eine Klasse "Product".
Also eine Klasse, viele Objekte der Klasse.

Bei Vererbung muß man die ".__init__()"-Methode der Oberklasse aufrufen. Dann erhält die Unterklasse automatisch alle Attribute und Methoden der Oberklasse. Diese können dann in der Unterklasse speziell angepaßt werden. Wieder ein kleines Beispiel:

Code: Alles auswählen

#!/usr/bin/env python
# coding: iso-8859-1

class Product(object):

    def __init__(self, price):
        self.price = price

class Car(Product):

    def __init__(self, price):
        Product.__init__(self, price)
        self.wheels = 4
        if self.price < 2000:
            print "Sorry, prices for cars start at 2000."
            print "Price for car set to 2000."
            self.price = 2000


singleproduct = Product(price = 50)
acar = Car(50)
print acar.price
anothercar = Car(2500)
print anothercar.price
print "A car has usually " + str(acar.wheels) + " wheels."

[deets]

@sprudel

Du solltest die Finger von Elixir lassen. Ich benutze das selbst, und leider wird es nicht mehr weiterentwickelt. Das liegt uA auch daran, dass SQLAlchemy declarative der neue Weg ist ORM in SA zu betreiben.

Auch dein Verstaendnis von Transaktionen scheint mir seltsam - eine Transaktion umfasst eine Menge von Operationen auf deinem Datenbestand, die geschlossen angewandt oder wieder Rueckgaengig gemacht werden koennen. Das hat aber zB nichts mit Angeboten zu tun, und umfasst auch nicht Verkauf & Retour gemeinsam - sondern immer dann, wenn Geld fliesst, ist das eine Transaktion. Also der Verkauf fuer sich, und eine Retour fuer sich.

[mutetella]

Wobei eine Retoure letztlich kein eigens definierter Vorgang sondern ein Verkauf mit negativen Vorzeichen ist. Was dann auch so in der Lagerverwaltung erscheint:

Code: Alles auswählen

Datum       Vorgang             Anzahl      Bestand
2012.02.09  Lieferschein 0001       10           10
2012.02.10  Barverkauf              -1            9
2012.02.13  Rechnung 0001           -2            7
2012.02.13  Gutschrift 0001          2            9

mutetella

[BlackJack]

Ich würde bei einem ORM auch eher die Tabellen entwerfen und nicht OOP betreiben. Die Frage ist also der Tabellenaufbau, aus dem sich die Objekte dann mehr oder weniger automatisch ergeben. Wenn man einfach so einen normalen OOP-Entwurf macht, habe ich die Erfahrung gemacht, dass man den hinterher nicht immer vernünftig auf Tabellen abbilden kann.

[sprudel]

Also, um das ganze nochmal zu klären.

Wir haben uns darauf geeinigt, dass es ein Product gibt, keine ProductDefinition oder irgendwas in der Richtung.
Und eine Transaktion (in meinem Fall ist damit, etwas unglücklich ausgedrückt, nicht die eigentliche Datenbanktransaktion, sondern ein gesamter Verkaufsvorgang mit Angebot, eigentlichem Verkauf, eventuellem Retouren, Belegtexten, etc. gemient)...
Das Product ist immer eindeutig, also auch wenn ich mehrere gleichartige Produkte einbuche, werden auch mehrere Objekte in die Datenbank erstellt.
Kann ich das so mal zusammenfassen?
Vielen Dank übrigens, bisher, für eure Hilfe.
Auf Elixir zu verzichten tut schon sehr weh, ist es doch wirklich sehr komfortabel... Ist es wirklich nötig?

[deets]

Es ist nicht "nötig", aber halt rottende Technologie. Irgendwann wird das zu einer Belastung.

[deets]

Und jetzt nochmal etwas ausfuehrlicher.

Dein Fokus scheint im Moment sehr auf den Produktinformationen zu liegen. Dabei sind die eigentlich das unspektakulaerste. Viel wichtiger sind die Modellierung von Angeboten (bindend oder nicht), Rechnungen, Mahnstufen, teilweisen oder kompletten Ruecktritten vom Kauf, Gutschriften usw.

Und zu dem ganzen Thema kann man hier problemlos stundenlang was schreiben - aber dazu fehlt zumindest mir die Zeit.

Ich habe nicht wirklich den Eindruck, dass dir der Umfang des ganzen bewusst ist. Ist das ganze denn mehr als nur ein Lernprojekt? Welchen Stand hat es? Wo soll es eingesetzt werden? Warum benutzt du keine existenten Loesungen?

[noisefloor]

Hallo,

in dem (wenn auch etwas älteren) Buch von o'Reilly zu SA wird Elexir als ideal für "development into the blue" beschrieben, im positiven Sinn. Soll wohl heißen, dass Elexir sich immer dann anbietet, wenn die eine Applikation entwickelts und deine DB-Modelle vielleicht mehrmals komplett umkrempelst.

Aber: Elexir kann (logischerweise) nichts, was SA nicht auch kann.

Zum eigentlichen Thema: nach dem letzten Post des OP ist ein "Vorgang" wohl das zentral Element. Von daher bietet es sich IMHO an, für jeden Vorgang eine einmalige und eindeutige ID zu vergeben und jedes Angebot, jeder Rechnung, jede... einem Vorgang zuzuordnen.

Oder du nimmst eine Dokumenten-Orientiert DB (wie CouchDB oder MongoDB) und erstellt für jeden Vorgang ein Dokument.

Gruß, noisefloor

[deets]

@noisefloor

Das Buch ist schlicht veraltet. Glaube mir - ich habe patches zu Elixir beigetragen & stand mit dem Autor in Kontakt. Das Projekt ist bestenfalls im maintenance-Modus. Der letzte commit ist ~13 Monate her, und inzwischen ueberholt declarative wohl.

[problembär]

... Viel wichtiger sind die Modellierung von Angeboten (bindend oder nicht), Rechnungen, Mahnstufen, teilweisen oder kompletten Ruecktritten vom Kauf, Gutschriften usw.
...
Ich habe nicht wirklich den Eindruck, dass dir der Umfang des ganzen bewusst ist. ... Warum benutzt du keine existenten Loesungen?

Seh' ich auch so. Klingt mir alles ein bißchen nach Lx-Office.
Könntest das ja von Perl nach Python übersetzen.

[noisefloor]

Hallo,

@deets:

Das Buch ist schlicht veraltet.

Keine Frage - es behandelts ja Version 0.4 von SA. Es ging mehr um die Aussage, wozu Elexir gut sein kann bzw. genau genommen: gut sein konnte.

Gruß, noisefloor