BlackJack hat geschrieben:Bei meinem Beispiel war das Laden eine statische Methode, also nichts was man auf einem fertigen Exemplar sondern nur auf der Klasse aufruft. Wenn das Laden aus einer Datei in der `__init__()` steckt, schränkt man sich IMHO unnötig ein. Zum Beispiel bei (automatischen) Tests, die dann nicht ohne Datei oder Zugriff auf ein Dateisystem funktionieren, oder dass man andere Möglichkeiten wie laden aus einer CSV-Datei, Mail-Programm-Adressbuch oder ähnliches als Alternative ausschliesst.
Ausserdem kann man in der `__init__()` nicht das gesamte Objekt laden sondern nur Teile/Attribute davon, weil das Objekt selbst zu dem Zeitpunkt schon besteht. Das man so ein Objekt nicht konstruieren kann ohne die Schlüssel zu kennen, ist eine unglückliche Trennung. Diese Information gehört IMHO mit in die Datei.
Das aktuelle Arbeitsverzeichnis zu dem Zeitpunkt als das Modul geladen wurde, als Ausgangspunkt für alle Lade- und Speichervorgänge zu benutzen ist sehr willkürlich und nicht das was man erwarten würde. Was ist denn der Sinn von dieser Aktion und auch der Fallunterscheidung zwischen 'Linux1' und 'win32' wenn eh in beiden Fällen das gleiche gemacht wird? Bei mir kommt bei `sys.platform` 'linux2' heraus, dass heisst das würde bei mir ziemlich auf die Nase fallen, weil der Dateiname nicht angehängt wird, und versucht wird das aktuelle Arbeitsverzeichnis als Datei zu öffnen.
`self.min_entries` kann man mit 0 initialisieren, dann braucht man einen Test weniger.
``del`` ist keine Funktion.
Irgendwie gefällt es mir nicht so gut, weil es als OOP-Beispiel furchtbar ist. Das würde man nie ernsthaft so entwerfen.
Zunächst mal zu "Linux 1" usw. Das hat nur was mit unserer Schule zu tun.
@edit
Aber es dämmert mir grad was....das ist gar nicht mehr nötig. Zu 99,9% hast du Recht ich brauch die Fallunterscheidung hier nicht......den Werdegang dieses Denkfehlers von mir erspar ich dir, ggg
Alles zum Thema laden() (automatische Tests usw.) war hier nicht vorgesehen. Nochmal: Beschränkung bedeutet oft leichteres Verständnis. Beim Programmieren der 4 Ansätze und ersten Tests habe ich gesehen, dass der 4. Ansatz oder vielleicht noch ein höher entwickelter wie deiner (Implementierung von __len__ usw.) zum Anfangen mit SchülerInnen zum Scheitern verurteilt ist. Warum denkst du sind in fast allen Schulen - ich rede nicht von HTLs udgl. - der Einsatz von Java im Unterricht zu einer Katastrophe geführt hat?
Ich finde es als OOPbeispiel gar nicht furchtbar, muss ich dir glatt widersprechen.
Es hat alle Aspekte, das ein OOPP haben sollten, dass man vieles besser machen kann ist ja eh klar.
Es ist dennoch vielseitig einsetzbar, nicht abstrakt und nicht falsch.
Die Sache mit dem Verzeichnis, dass man das nur so festlegen sollten, wenn kein Pfad angegeben wird, habe ich mir auch schon mal gedacht.
Die Idee mit min_entries klingt auch gut, sehe ich mir an.
Warum ist del keine Funktion, anders gefragt, wie sollte ich es ändern in meinem furchtbaren Code:-)
LG
rolgal_reloaded