Seit 2002 Diskussionen rund um die Programmiersprache Python
https://www.python-forum.de/
Dazu müßte man doch genau wissen, was diese Klasse leisten soll. Mir ist es im Moment nicht klar (und aus Deinem undokumentierten Ansatz geht das auch imho nicht hervor).sprudel hat geschrieben:Ich weiß, es ist eine blöde Frage, und hier so eigentlich nicht erwünscht.
Aber kann mir hier jemand mal ein grobes Beispiel (gerne auch schemenhaft) einer Beispielklasse (z.B. Transaction) machen, so wie ich das in SQLAlchemy lösen müsste?
Ich denke, dass diese zusätzliche Eben durchaus berechtigt ist: Möchte man zumeist nicht wissen, wenn ein - vermutlich als intern gedachtes, also mit _ prefixen (cooles WortHyperion hat geschrieben:- "addProduct" kapselt letztlich direkt nur die append-Methode einer Liste. Daher kann man sich so etwas auch sparen.
) - Attribut verändert wird. Im jetzigen Zustand mag das noch nicht erforderlich sein, aber ich denke, dass er gewisse Aktionen ausführen will, sobald ein Produkt hinzugefügt oder entfernt wird, sodass die Daten untereinander konsistent sind. Nur solche Attribute, die ohne Komplikationen geändert werden dürfen, sollten als public markiert werden.In diesem Fall würde ich dir zustimmen. Besteht die Berechnung des Properties aus mehr als nur ein paar einfachen Statements, so würde ich doch eher zu einer explizizen getter-Methode greifen, um ersichtlich zu machen, dass es eben keine simple Operation ist.dieses "getPrice()" einer vermuteten Product-Klasse riecht auch zu sehr nach Java. Anstelle von Gettern und Settern nutzt man in Python eher Properties; sofern Du keine weiteren Tests oder Berechnungen in den Methoden vornimmst, kann man auch einfach direkt auf das Attribut zugreifen.
Ich bin ja auch vom jetzigen Zustand ausgegangensyntor hat geschrieben: Ich denke, dass diese zusätzliche Eben durchaus berechtigt ist: Möchte man zumeist nicht wissen, wenn ein - vermutlich als intern gedachtes, also mit _ prefixen (cooles Wort
Wenn solche "Aktionen" tatsächlich notwendig sind, ist eine Methode natürlich erforderlich - aber dann kann ich sie ja immer noch einfügen. Vom Ausdruck "public" in Zusammenhang mit Attributen in Python würde ich übrigens absehen; das riecht zu sehr nach Zugriffskontrolle und weniger nach Konvention. Oben schreibst Du ja auch - wohl bewusst - intern.Hm... kommt imho drauf an. Bei komplexen und vor allem teuren Operationen handelt es sich ja zumeist auch nicht um das reine Setzen von Attributen, sondern um Funktionalität, die einem eine Klasse bietet. Da benennt man diese ja eh nach dieser. Ich war jedenfalls noch nie in so einer Situation, in der eine property zu komplex war.In diesem Fall würde ich dir zustimmen. Besteht die Berechnung des Properties aus mehr als nur ein paar einfachen Statements, so würde ich doch eher zu einer explizizen getter-Methode greifen, um ersichtlich zu machen, dass es eben keine simple Operation ist.
Ich habe mir das so vorgestellt, dass ein gesamter Verkaufsprozess dort erfasst wird. Also die Produktobjekte, das Kundenkonto, eine Liste von Transaktionen (also z.B. Storno, oder Rabatt, reiner Text und Zeitangabe. Wird wohl wieder ein kleines Objekt werden.Dazu müßte man doch genau wissen, was diese Klasse leisten soll. Mir ist es im Moment nicht klar (und aus Deinem undokumentierten Ansatz geht das auch imho nicht hervor).
Habe mir beide schon etwas angeschaut, werde das aber nochmal gründlich wiederholen.Evtl. magst Du Dir doch zuerst mal Elixir angucken? Trotz der mittlerweile vorhandenen deklarativen Syntax bei SQLAlchemy halte ich Elixir immer noch für einfacher. Schau Dir doch da mal das Tutorial an - einfacher geht der Einstieg kaum (und er ähnelt Deinem Ansatz von der Komplexität hier ziemlich).
Das war jetzt nur kurz in Gedit geschrieben, normalerweise verwende ich Eclipse, und da ist das schon voreingestellt.- beachte mehr PEP8, Einrückungen sollten 4 Spaces sein, Funktionen und Methoden werden klein_und_mit_underscore benannt. Zwischen Paramertern und dem abgrenzenden Komma immer ein Space
Ich habe bereits an die Zukunft gedacht... und ich rechne damit, dass da nochmal was an Funktionalität dazu kommen wird.- "addProduct" kapselt letztlich direkt nur die append-Methode einer Liste. Daher kann man sich so etwas auch sparen.
Erwischt, wobei es bei mir eher C++ mit wxWidgets ist. und bei wxWidgets heißen die Methoden nunmal so... und das hat mir eben gefallen.- dieses "getPrice()" einer vermuteten Product-Klasse riecht auch zu sehr nach Java. Anstelle von Gettern und Settern nutzt man in Python eher Properties; sofern Du keine weiteren Tests oder Berechnungen in den Methoden vornimmst, kann man auch einfach direkt auf das Attribut zugreifen.
Das ist jetzt aber reine Datenhaltung und spiegelt keinerlei Funktionalität wieder. Also ich denke nicht, dass Dir hier jemand daraus etwas bastelt. Ich würde an Deiner Stelle eben einfach selber anfangen, das alles Schritt für Schritt zu implementieren. Du wirst eh das ein oder andere wegschmeißen und dank neuer Erkenntnisse nach implementieren müssen.sprudel hat geschrieben: Ich habe mir das so vorgestellt, dass ein gesamter Verkaufsprozess dort erfasst wird. Also die Produktobjekte, das Kundenkonto, eine Liste von Transaktionen (also z.B. Storno, oder Rabatt, reiner Text und Zeitangabe. Wird wohl wieder ein kleines Objekt werden.
Auch schon mal camelot? Imho könnte das genau das richtige für Dich sein!Habe mir beide schon etwas angeschaut, werde das aber nochmal gründlich wiederholen.
Aber nicht die BenennungDas war jetzt nur kurz in Gedit geschrieben, normalerweise verwende ich Eclipse, und da ist das schon voreingestellt.- beachte mehr PEP8, Einrückungen sollten 4 Spaces sein, Funktionen und Methoden werden klein_und_mit_underscore benannt. Zwischen Paramertern und dem abgrenzenden Komma immer ein Space
Wir haben bei unserer Warenwirtschaft mittlerweile 378 Tabellen. Ich hoffe nicht, dass es jemand in seiner Freizeit so weit treiben will.burli hat geschrieben:Es hängt davon ab, wie weit du das treiben willst. Um es einfach nur mal auszuprobieren reichen die vier Klassen für den Anfang
Kann es sein, dass es da einer mit der Normalisierung etwas übertrieben hat?Noah hat geschrieben:Wir haben bei unserer Warenwirtschaft mittlerweile 378 Tabellen. Ich hoffe nicht, dass es jemand in seiner Freizeit so weit treiben will.
Man muss nicht für jede Spalte eine eigene Tabelle anlegen. Man kann auch mehrere thematisch zusammengehörende Spalten zusammenfassen 
Das kommt auf die Größe des Kunden an. Ich hab mal die Gesamtanzahl auf einer großen Kundendatenbank ermittelt:Xynon1 hat geschrieben:@Noah
Jetzt wäre es natürlich noch interessant wieviele Datenssätze auf die 378 Tabellen kommen. Einfach nur um sich auch so wie burli darüber zu amüsieren
Ja, wenn ich den bekloppten Rechnungsdruck wieder zum Laufen bekomme... Und von der Statistik will ich gar nicht reden. Ist alles Code der alle VB-Versionen ab 1.0 durchgemacht hat und jetzt auf VB.NET portiert wird.Xynon1 hat geschrieben:Nett, noch nicht die Welt, aber dennoch nett, für ein paar Rechnungen, Statistiken und andere kleinere Auswertungen wird es wohl reichen