richtiger Aufbau eines größeren Programms...

[genrich]

Hi...

Ich hab zwar jetzt schon ein bischen in Python rumprogrammiert und gelesen. Aber ich frage mich, wie man am besten ein größeres Programm aufbauen sollte...
Natürlich sollte es am besten so sein, das man es beliebig erweitern kann...

Dabei ist mir noch immer nicht ganz klar, wann es am Sinnvollsten ist Klassen (class) zu schreiben und wann einfach nur Funktionen (def)...

Außerdem hab ich das Problem, das ich einige Unterroutinen z.B. FileIO.py im Hauptprogramm und gleichzeitig in anderen Unterroutinen benutzte... d.h. ich imporiere es im Grunde mehrmals... Das ist doch nicht Sinn der Sache, oder???

Eine Lösung für Globale Variablen haben wir ja schon hier: http://python.sandtner.org/viewtopic.php?p=9452#9452
Aber so richtig Pratisch ist das ja nicht...

Mir erscheit, als ob die die Philosophie von Python noch nicht richtig verstanden hab... Kennt jemand ein gutes Buch über dieses Problem???

[Dookie]

Hi...

Hi auch

Ich hab zwar jetzt schon ein bischen in Python rumprogrammiert und gelesen. Aber ich frage mich, wie man am besten ein größeres Programm aufbauen sollte...
Natürlich sollte es am besten so sein, das man es beliebig erweitern kann...

Größere Programme sollte man in kleine Häppchen zerlegen, die dann einzeln getestet werden können und oft fallen dann auch Module an, die in anderen Programmen auch Verwendung finden. Oft ist es auch sinvoll, die GUI vom eigentlichen Programm zu trennen. So ist es relativ leicht Programme für andere GUI-Systeme umzuschreiben oder auch die GUI zu erweitern.

Dabei ist mir noch immer nicht ganz klar, wann es am Sinnvollsten ist Klassen (class) zu schreiben und wann einfach nur Funktionen (def)...

Leider helfen da auch die meisten Bücher nicht weiter, viele Bücher in denen es um OOP (Objektorientierte Programmierung wo man Klassen verwendet) geht, Zeigen dann Beispiele, die mit Prozeduralem Ansatz (mit def) oft viel einfacher zu lösen sind. OOP hat IMHO viel mit Fraktalen zu tun, überall da wo mit Daten gearbeitet wird, die gemeinsame Eigenschaften haben (Selbstähnlichkeit), ist OOP sehr sinvoll. Wo man mit Standartdatentypen auskommt ist OOP oft eher ein Hemmschuh.

Außerdem hab ich das Problem, das ich einige Unterroutinen z.B. FileIO.py im Hauptprogramm und gleichzeitig in anderen Unterroutinen benutzte... d.h. ich imporiere es im Grunde mehrmals... Das ist doch nicht Sinn der Sache, oder???

Eigentlich ist genau das Sinn von Modularisierung. Wenn Du in Python ein Modul importierst, wird es nur beim erstenmal wirklich importiert und auch initialisiert, bei jedem weiteren Importieren schaut Python in einem internen Dictionary (sys.modules) nach, ob das Modul schon importiert wurde und holt daraus den Zeiger auf das Modul, der dann an die importierende Instanz zurückgegeben wird.

Eine Lösung für Globale Variablen haben wir ja schon hier: http://python.sandtner.org/viewtopic.php?p=9452#9452
Aber so richtig Pratisch ist das ja nicht...

Globale Variablen sollten auch so weit wie möglich vermieden werden. Dafür gibts Klassen. Eine Klasse sollte alles was für das Bearbeiten der Objekte die mit dieser Klasse instanziiert werden als Methoden oder Attribute zur Verfügung stellen.

Mir erscheit, als ob die die Philosophie von Python noch nicht richtig verstanden hab... Kennt jemand ein gutes Buch über dieses Problem???

Bücher gibts sicher viele, ich hab einiges aus meinen alten Büchern von N. Wirth (Modula2 Oberon) gelernt, hatte aber den Vorteil, daß ich schon vorher, eher unbewusst auf dem Amiga in 68k-Assembler Objektorientierte Ansätze verwendet habe.
Z.B. hatte ich ein kleines Programm geschrieben, daß auch Gadgets (grafische Buttons) verwendet hat. Nun dachte ich mir, es wär ja schön, wenn der Button selber wüsste, welche Funktion mit ihm verknüpft ist, das würde eine ganze Reihe von Abfragen einspaaren. Die Gadgets beim Amiga hatten in ihrer Datenstruktur ein Feld, "userdata", das eben für beliebige Daten da war. in dieses Feld hab ich einfach einen Zeiger auf die Funktion die mit dem Gadget verknüpft werden sollte eingetragen und in der Hauptschleife brauchte ich nur über dieses feld den Zeiger holen und die entsprechende Funktion aufrufen. Damals wusste ich noch gar nicht, daß es Objektorientierte Programmierung gibt.


Gruß

Dookie