Strukturierung eines Programms im Sinne der Objektorientierung

[muxe]

Hi!
Ich habe angefangen mich mit Python zu beschäftigen und bin sehr begeistert davon wie einfach man eine plattformübergreifende GUI erstellen kann.
Ich weiß nur nicht so richtig wie ich ein schönes Programm erstellen soll, das in Modulen gekapselt ist.

Was ich umsetzen möchte:
Ein Programm, das eine PDF Datei läd, sie parsed, die Daten in eine DB schreibt und dan einer anderen Stelle diese wieder anzeigt.

Ich kann das schon einfach runtercoden, aber ich würde es gerne mit mehreren Klassen sauber gestalten.
Habe eine main.py gemacht, in der ich die GUI erzeuge. Die Klasse MainWindow erzeugt ein Objekt der Klasse PDFWindow, das dann auch geöffnet wird und ein Button mit dem ich das PDF auswähle habe ich auch.

Jetzt würde ich eigentlich gerne in einer anderen Datei eine PdfReader-Klasse bauen, die in der GUI-Klasse nur aufgerufen wird.
Allerdings erschließt sich mir dann noch nicht so ganz wie ich das mit dem Error-Handling hinbekommen soll. Wie kommt von der PDF-Klasse dann die Info wieder zur GUI-Klasse. Es ist ja keine Funktion/Methode, sondern ein Klassenobjekt.

Hat einer einen Tipp wo ich die Strukturierung eines Programms im Sinne der Objektorientierung lernen kann?
Wenn man das googled kommen immer so einfach Beispiele wie ein Auto mit 4 Türen, das wieder eine Child-Class Motor hat, etc.

Danke

[pillmuncher]

Wenn man das googled kommen immer so einfach Beispiele wie ein Auto mit 4 Türen, das wieder eine Child-Class Motor hat, etc.

Laut diesen Beispielen hat also ein Motor vier Türen? Weil, eine Vererbungsbeziehung ist ja eine is-a-Beziehung. Im Gegensatz zur has-a-Beziehung, die man durch Komposition umsetzt, etwa wenn ein Auto einen Motor hat.

Zu deiner Frage: normalerweise macht man das so, dass man eine Sammlung von Klassen und Funktionen zur Verfügung stellt, in denen die eigentliche Arbeit verrichtet wird (PDF-Datei öffnen und schließen, in Datenstrukturen parsen, mit den geparsten Daten irgendwas anstellen, zB. in eine Datenbank schreiben, etc.). Diese Klassen und Funktionen werden dann von der GUI verwendet, indem sie deren Interaktion steuert, ohne dass diese wissen, dass es die GUI überhaupt gibt. Dadurch wird es möglich, sie auch in einem Konsolen- oder Batch-Programm zu verwenden. Du musst also genau andersherum denken - nicht, wie steuere ich die GUI aus meinen Klassen und Funktionen heraus, sondern umgekehrt, wie müssen die Klassen und Funktionen aussehen, damit sie zB. von einer GUI verwendet werden können, ohne diese GUI überhaupt kennen zu müssen. Callbacks sind zB. eine Möglichkeit, sowas zu bewerkstelligen. Um da konkretere Ratschläge zu geben, müsste ich mehr über dein Programm wissen.

Für IO-Operationen gilt übrigens dasselbe, wie für GUIs - nicht mit der internen Logik verhaken, damit man zB. auch einfache Strings an eine Parserfunktion übergeben kann, und nicht erst den String in eine Datei schreiben muss, weil die Funktion meint, sie müsse unbedingt selber irgendeine Datei öffnen und den String daraus einlesen. Wenn man Tests schreibt, möchte man doch gerne auf IO verzichten, weil IO die Tests deutlich verlangsamt, und langsame Tests sind so gut wie keine Tests, weil man sie nicht laufen lassen mag.

[__blackjack__]

Ergänzend zu pillmuncher würde ich noch hervorheben wollen, dass ich es für keine gute Idee halte auf biegen und brechen Klassen zu schreiben um objektorientierte Programmierung zu üben. Zum Umgang mit Klassen gehört auch, dass man lernt wann man sie *nicht* verwendet. Wenn man keinen Zustand hat, den man sinnvoll mit Funktionen zusammen in einem Objekt bündeln kann, dann sollte man keine Klasse(n) schreiben, die auch einfach(er) mit Funktionen implementiert werden könnten.

[muxe]

Danke für eure Antworten.
Insbesondere der Tipp mit den einfachen Funktionen, die z.B. einen String übergeben bekommen, war sehr gut. Ich glaube ich habe es jetzt gut strukturiert hinbekommen was ich versucht habe.

Den letzten Tipp habe ich auch angenommen und eine Funktionssammlung genutzt statt eine "Arbeitsklasse" zu bauen.