Das deutsche Python-Forum

Ok, bin erstmal einen Schritt zurückgegangen. Hier die neue Datei: https://github.com/toxinman/stuff/blob/ ... essbuch.py

@ Xfd7887a: was soll das eigentlich für eine ID sein? Wenn IDs nicht eindeutig sind, was ist dann der Sinn einer ID. Bei loeschen entfernst Du Elemente aus einer Liste, über die Du iterierst. Das führt zu unvorhergesehenem Verhalten. In Deinem Fall würde aber auch ein 'remove' auf der Liste reichen.
Suchen liefert jetzt eine Liste zurück, so dass aendern und loeschen nicht mehr funktioniert.

Ja, weil ich nicht weiß, wo jetzt das Abfragen, welches Suchergebnis das richtige ist, erfolgen soll.

Der Sinn einer ID ist es zudem auch, dass man einen Datensatz anhand dieser leicht ermitteln kann. Insofern böte es sich an, die äußere Liste durch ein Dictionary zu ersetzen und darin die ID als Schlüssel und ein zugehöriges Adressen-Dict als Wert abzubilden. Damit kannst Du das ``loeschen`` über die ID erledigen und musst nicht mehr iterieren.

Ich habe mal weiter gearbeitet: https://github.com/toxinman/stuff/blob/ ... essbuch.py Sorry für die lange Pause

Kann ich mich jetzt an die Gui machen oder muss ich noch etwas ändern?

@Xfd7887a: das mit dem Suchen ist ja immer noch nicht so toll. Aber was Du haben willst, mußt Du selbst wissen.
Da Du für GUI sowieso Klassen brauchst, kannst Du ja mal zur Übung Deine Addressen in eine Klasse verwandeln.

Da Du für GUI sowieso Klassen brauchst, kannst Du ja mal zur Übung Deine Addressen in eine Klasse verwandeln.

Also muss ich alle Funktionen in eine Klasse stecken?

Edit: Das Auswählen des richtigen Suchergebnis müsste ja theoretisch mit der GUI gemacht werden.

Xfd7887a hat geschrieben: Also muss ich alle Funktionen in eine Klasse stecken?

Alle natürlich nicht - nur diejenigen, die sinnvoll für die (jeweilige) Klasse sind Die Frage ist halt nach wie vor, ob man bei dem bisherigen Entwurf tatsächlich Klassen braucht und wo man diese sinnvoller Weise einsetzen könnte.

Xfd7887a hat geschrieben: Edit: Das Auswählen des richtigen Suchergebnis müsste ja theoretisch mit der GUI gemacht werden.

Das kann und sollte auch *ohne* GUI funktionieren. Ich habe mir den aktuellen Stand zwar schon länger nicht mehr angeguckt, aber iirc sind da noch einige unschöne und störende Elemente in dem bisherigen Entwurf.

Wieso baust Du nicht erst einmal ein textuelles UI mit dem bisherigen auf? Also eines, in dem der Benutzer wirklich über einfache Menüs Aktionen rund um das Adressbuch nutzen kann? Imho wirst Du dann noch besser verstehen, was ein gutes API können muss.

Ok, das werde ich machen

Muss ich dann alle Eingaben in extra Funktionen packen?

Xfd7887a hat geschrieben:Muss ich dann alle Eingaben in extra Funktionen packen?

Verstehe Deine Frage so nicht. Wie genau meinst Du das?

Wohin muss die Eingabe? Du sagtest ja, dass sie nicht in die jeweiligen Funktionen darf. Also müssen sie ja irgendwo anders hin Nur wohin? In extra Funktionen oder einfach in Main rein?

Muss ich es in der Art machen: ?

Um die Selbständigkeit zu verbessern: Was denkst Du denn? Versuche (letztlich auch Dir selber) zu erklären, wieso Du solch eine Funktion für sinnvoll hältst. Überlege Dir, ob und welche Alternativen Dir einfallen und überlege, was da Vor- und Nachteile sein könnten...

Ich würde so eine Funktion für sinnvoll halten, da sie später einfach durch die GUI ersetzt werden kann Oder nicht?

Die Begründung ist nicht wirklich stichhaltig - alles, was eine TUI und eine GUI *nicht* gemeinsam haben, sind per se voneinander unabhängig Dinge. Insofern kannst Du keine Sinnhaftigkeit für Deine TUI daraus schlussfolgern. Aber: Wichtig ist, *dass* Du Funktionen aus dem Kern Deiner Domäne nutzt, um ein TUI zu realisieren! Das legt schon mal nahe, dass man später diese Funktionen *auch* aus einer GUI nutzen kann (und sollte!). Für Deine Frage ist es aber wichtiger zu gucken, *wie* Dein TUI gegliedert sind soll und wie Du welche Operation aufrufst. Stellst Du dabei fest, dass Du immer wieder ähnlichen Code schreibst, um Benutzereingaben abzufragen, so musst Du dann prüfen, ob man solche Funktionalität auch in eine gemeinsame Funktion bündeln kann. Fürs erste sieht mir das hier aber ok aus.