Das deutsche Python-Forum

Hallo zusammen,

ich habe die letzten Wochen an einem eher größeren Projekt gearbeitet. Bei diesem Projekt geht es um ein fiktives Banking System.
Das Projekt ist unter hier aufrufbar: https://github.com/crazyyzarc/Banking-System-public

Das Projekt umfasst derzeit folgende Funktionen:
- Erstellung von Kunden, Banken und Bankkonten
- Interaktion mit den Bankkonto wie Abheben, Überweisen und Einzahlen
- Eingabe erfolgt durch die CLI (Command Line Interface)
- Logger Funktionalität zum debuggen
- Eigene Exceptions, um spezifischere Anwendungsfälle zu differenzieren und auswerten zu können

Mein Problem derzeit ist es, dass ich nicht mehr als ein Benutzerkonto (cli_instance) benutzen kann. Aber wenn ich halt über die Instanz (cli_instance) alle gespeicherte Informationen durch eine Neuerstellung überschreibe, kann ich keinem anderen Benutzer Geld überweisen. Mein bisheriger Versuch war es, die Entries Klasse in der Hauptdatei (banking.py) zu benutzen, die alle Kundeninformationen bis zum Ende der Programmausführung speichert und im Zugriff bereit hält. Klappt nicht so toll wie ich es mir vorgestellt habe, denn ich weiß noch nicht ganz so genau wie ich die Bentuzerinformationen speichern und später auf die zugreifen soll.

Der Informationsstring ist derzeit viiiel zu lang oder weiß meint ihr?

Wäre über paar Ratschläge sehr zufrieden

Code: Alles auswählen

{'ID': 1, 'Customer': {'Firstname': 'Max', 'Lastname': 'Mustermann', 'Gender': 'm', 'Birth': {'Day': '19', 'Month': '04', 'Year': '1995'}, 'Address': 'Postweg 5', 'Postcode': '53111', 'City': 'Bonn'}, 'BankCorp': {'Name': 'Dkb', 'Address': 'Der heiße Weg 2', 'Postcode': '53235', 'City': 'bonn'}, 'Bankaccount': {'Customer': {'Firstname': 'Max', 'Lastname': 'Mustermann', 'Gender': 'm', 'Birth': {'Day': '19', 'Month': '04', 'Year': '1995'}, 'Address': 'Postweg 5', 'Postcode': '53111', 'City': 'Bonn'}, 'Bank name': {'Name': 'Dkb', 'Address': 'Der heiße Weg 2', 'Postcode': '53235', 'City': 'bonn'}, 'Balance': 4000, 'Max daily transfer': 500, 'Max transfer': 10000}}

Du benutzt globale Variablen. Nämlich mindestens cli_instance. Schmeiß die weg, dann wird sich ein Problem von selbst erledigen:

Auf Modulebene stehen nur die Definition von Funktionen, Klassen und Konstanten.
Mindestens cli_instance, crm, log und logged_in sind da also falsch. Wobei log sinnvoll sein könnte, der Rest allerdings garantiert nicht.

Und um das zu erreichen:
Funktionen bekommen alles, was sie zum arbeiten brauchen, als Argumente und geben ein Ergebnis via return zurück.

Das wendest du jetzt konsequent auf deinen Code an und dann wirst du deine Probleme los.

sparrow hat geschrieben: Freitag 24. Juli 2020, 10:42 Du benutzt globale Variablen. Nämlich mindestens cli_instance. Schmeiß die weg, dann wird sich ein Problem von selbst erledigen:

Auf Modulebene stehen nur die Definition von Funktionen, Klassen und Konstanten.
Mindestens cli_instance, crm, log und logged_in sind da also falsch. Wobei log sinnvoll sein könnte, der Rest allerdings garantiert nicht.

Und um das zu erreichen:
Funktionen bekommen alles, was sie zum arbeiten brauchen, als Argumente und geben ein Ergebnis via return zurück.

Das wendest du jetzt konsequent auf deinen Code an und dann wirst du deine Probleme los.

Danke für diesen Tipp, äh.. da muss ich erstmal nachdenken wie ich da vorgehen werde.

Also noch mal zum Verständnis: die Hauptklasse (hier banking.py) soll nur die Funktionen, Klassen und Kostanten enthalten. Alles andere wie Eingaben werden in Subklasse geregelt. Die Informationen über Kunden, Bank und Bankkonto werden dann entweder seperat in einem eigenen Modul oder in customer.py selbst erfragt, erstellt und verwaltet. Und die aktuelle Benutzer Session (cli_instance) sowie alle anderen Sessions werden nicht in banking.py regelt sondern ebenso in einem Submodul?! Somit auch die input Funktion, die als cli handler fungiert soll ich nicht in das Hauptprogramm packen?! (wie in https://github.com/crazyyzarc/Banking-S ... ng.py#L223)

Neee. Auf Modulebene betrifft ja auch Submodule.

Der Aufruf der main-Methode sollte immer so aussehen:

Code: Alles auswählen

if __name__ == "__main__":
    main()

Nicht mehr, nicht weniger.

Und dann dürfen in einem Python-Quellcode außer der Definition von Klassen, Funktionen und Konstanten nur noch die Importe uneingerückt stehen. Mehr nicht. Das hat also nichts mit Submodulen zu tun.
Und eben die obige Abfrage, ob es sich im das gestartete Modul handelt.

Ich hab mir nur mal die Datei banking.py angeschaut, und da gibt es so einiges zu verbessern.
`Entries` ist keine Klasse, weil `self` nirgends benutzt wird. Das ist einfach nur ein Haufen globaler Variablen. `add_entries` tut je nach Typ des übergebenen Arguments etwas anderes. Statt Typprüfungen solltest Du einfach eine add_customer, add_corp und add_account-Methode schreiben.
Die Typannotationen sind alle komplett sinnlos und können weg. In Python ist alles ein Objekt, bei einer Variable cli_objekt bietet das Postfix keinen Mehrwert.
Alles was eine Funktion braucht, muß sie über ihre Argumente bekommen, get_create fehlt z.B. crm, wobei ich bei der kryptischen Zeichenfolge wirklich überhaupt keine Ahnung habe, was die bedeuten soll. `cli_instance` fehlt auch, vielleicht sollte das auch cli_object sein. Bei _instance gilt übrigens das selbe wie für Objekt. Alles ist irgendwie eine Instanz einer Klasse, selbst Klassen. Was soll überhaupt eine Funktion tun, die get_create heißt? Alle get_...-Funktionen holen aber auch gar nichts, sind also falsch benannt.
Mit *-Argumenten sollte man sparsam sein. Hier scheinen die get-Funktionen nur irgendwelche anderen Funktionen mit (hoffentliche festen Parametern) aufzurufen, dann schreib auch bei den get-Funktionen konkrete Parameter hin.
Vielleicht sollte man die get-Funktionen auch gleich ganz löschen.

Sirius3 hat geschrieben: Freitag 24. Juli 2020, 12:28 Ich hab mir nur mal die Datei banking.py angeschaut, und da gibt es so einiges zu verbessern.
`Entries` ist keine Klasse, weil `self` nirgends benutzt wird. Das ist einfach nur ein Haufen globaler Variablen. `add_entries` tut je nach Typ des übergebenen Arguments etwas anderes. Statt Typprüfungen solltest Du einfach eine add_customer, add_corp und add_account-Methode schreiben.
Die Typannotationen sind alle komplett sinnlos und können weg. In Python ist alles ein Objekt, bei einer Variable cli_objekt bietet das Postfix keinen Mehrwert.
Alles was eine Funktion braucht, muß sie über ihre Argumente bekommen, get_create fehlt z.B. crm, wobei ich bei der kryptischen Zeichenfolge wirklich überhaupt keine Ahnung habe, was die bedeuten soll. `cli_instance` fehlt auch, vielleicht sollte das auch cli_object sein. Bei _instance gilt übrigens das selbe wie für Objekt. Alles ist irgendwie eine Instanz einer Klasse, selbst Klassen. Was soll überhaupt eine Funktion tun, die get_create heißt? Alle get_...-Funktionen holen aber auch gar nichts, sind also falsch benannt.
Mit *-Argumenten sollte man sparsam sein. Hier scheinen die get-Funktionen nur irgendwelche anderen Funktionen mit (hoffentliche festen Parametern) aufzurufen, dann schreib auch bei den get-Funktionen konkrete Parameter hin.
Vielleicht sollte man die get-Funktionen auch gleich ganz löschen.

Danke für die Hinweise. Bei der Thematik mit den Argumenten, war ich bisher gezwungen mittels *-Präfix zu arbeiten. Denn der "cli-handler", der die Eingabe verarbeitet, reicht die Argumente an die passende Funktion aus dem Commands Dictionary weiter. Bei den Funktionen variiert natürlich die Parameteranzahl und somit würde es hierbei zu 'zu viele' oder zu 'zu wenige' übergebene Argumenten kommen. Hm.. ich denke darüber nach dieses Hindernis mit default Argumenten oder die Eingabe vorher anhand der länge der übergebenen Argumente zu handeln.

Wegen der Variablen Benennung werde ich genauer drauf achten keine "Doppelgemoppel" Deutigkeiten und auch aussagekräftigere Variablen zu nehmen. crm war für mich eher so eine experimentelle Funktion, die halt ein Kundenstamm repräsentiert auf den ich bei Bedarf zugreifen kann. crm steht für Customer Relationship Management

Das deutsche Python-Forum

Banking System mit mehrere Benutzeranmeldungen

Banking System mit mehrere Benutzeranmeldungen

Re: Banking System mit mehrere Benutzeranmeldungen

Re: Banking System mit mehrere Benutzeranmeldungen

Re: Banking System mit mehrere Benutzeranmeldungen

Re: Banking System mit mehrere Benutzeranmeldungen

Re: Banking System mit mehrere Benutzeranmeldungen