Architektur Python <-> Java

[adenied]

Hi Alle,

ich bin neu in der Sprache Python, programmiere aber seit 20 Jahren in Java. Ich habe ein Buch über Python gelesen, und ja, so im Großen und Ganzen ist mir klar, wie ich in Python Programme schreibe. Aber ... als Projekt wollte ich nun ein umfangreicheres Programm in Angriff nehmen, mit GUI auf wxPython basierend. Und genau hier tue ich mich schwer.

In Java habe ich Swing verwendet. Die Architektur der GUI war bei mir eigentlich immer gleich: Klassen von JFrame und JPanel abgeleitet. Modellklassen, welche die GUI füllen, Controllerklassen, die Interfaces implementieren, die von Swing gestellt werden. Zum Beispiel habe ich einem Button einen ActionHandler zugewiesen, der hat ggf. beim Klick das Modell aktualisiert, aber auch unter Umständen Änderungen in der GUI vorgenommen (z.B. ein Eingabefeld auf inaktiv gesetzt).

Nun stelle ich mir die Frage, inwiefern die Vorgehensweise in Python / wxPython damit vergleichbar ist. Interfaces gibt es als Sprachkonstrukt ja nun gar nicht. Pseudo-Zyklische Abhängigkeiten (z.B. der Button kennt das Interface des ButtonHandlers, dass von einer konkreten eigenen Klasse implementiert wird, welche wiederum die GUI kennt, um dann die GUI dynamisch zu ändern), lassen sich 1:1 so nicht umsetzen. Sicherlich lässt sich das irgendwie mit Brecheisen, Hammer und Säge hinbekommen, die Frage ist aber: soll ich das überhaupt versuchen? Neben all den kleinen Beispielen aus den Büchern und dem Internet fehlt mir eine Idee dazu, wie ich die Architektur in Forum von Packages und Modulen in Python im Rahmen einer komplexeren GUI Anwendung umsetzen sollte, damit Python Programmierer nicht die Hände über dem Kopf zusammen schlagen.

Hat da jemand von euch vielleicht ein bisschen Online-Literatur zu?

[__blackjack__]

@adenied: So ganz allgemein: Man muss in Python nicht alles in Klassen stopfen, es gibt auch Funktionen, und es ist okay die zu schreibe/verwenden. Für so etwas wie `ButtonHandler` braucht man vor allen deswegen keine eigene Klasse weil in Python alles was man an einen Namen binden kann ein Objekt ist. Das beinhaltet auch Module, Funktionen, Klassen, und Methoden. Für Rückrufe, zum Beispiel von Schaltflächen kann man also einfach irgend etwas aufrufbaren, in der Regel eine Funktion oder Methode angeben und es ist technisch egal wo die definiert ist. Bei `wx` ist das ”Interface” dafür in der Regel dass es eine Funktion oder Methode sein muss die ein Argument erwartet — ein Objekt, welches das Ereignis näher beschreibt. Das wird oft auch einfach ignoriert, wenn die Tatsache das die Funktion/Methode aufgerufen wurde an sich schon alles ist was man wissen muss.

Es gibt kein ``private`` wie in Java. Doppelte führende Unterstrichen sind *nicht* ”private”. Man kommt da trotzdem dran, die werden bloss nach einem definierten Muster umbenannt. Das ist ein Mechanismus um Namenskollisionen bei Mehrfachvererbung und tiefen Vererbungshierarchien zu vermeiden. Beides macht man in Python nur sehr selten, dementsprechend selten braucht man doppelte führende Unterstriche. *Ein* führender Unterstrich ist die Konvention für Implementierungsdetails, die von aussen nicht verwendet werden sollten.

Module sind Namensräume. Also nicht eine Klasse pro Datei schreiben, denn das wäre als wenn man in Java jede Klasse einzeln noch mal in ein eigenes Package stecken würde. Was keinen Sinn macht.

Keine trivialen Getter und Setter: Das macht man in Python nicht. Da greift man einfach auf das Attribut zu. Sollte man die API an der Stelle mal ändern müssen, gibt es `property()` um Methodenaufrufe die etwas setzen/abfragen von aussen wie einfache Attribute aussehen zu lassen.

Vergiss MVC allgemein. Das gibt es nicht. So ziemlich jedes GUI-Rahmenwerk was ”MVC” implementiert, hat eine eigene Vorstellung davon was das genau bedeutet. Also versuche nicht Swing nachzubauen, sondern schau Dir an was das GUI-Rahmenwerk für eine Aufteilung anbietet. Sonst programmiert man am Ende noch eher gegen das GUI-Rahmenwerk, statt mit dem GUI-Rahmenwerk. `wx` ist da sehr simpel gestrickt, das bietet da eigentlich gar nichts. Man merkt dem so ein bisschen das alter an. Mittlerweile kann man auch Objekte an vielen Stellen übergeben wo ursprünglich mal eine Menge opaker IDs die für die Objekte standen, übergeben wurden. An einigen Stellen scheint das glaube ich auch bei wxPython 4.x noch durch.

Namenskonventionen: In Python eigentlich klein_mit_unterstrichen. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (MixedCase). `wx` ist da superekelig weil die sogar Methoden *teilweise* wie Klassen schreiben.

Ich würde da einfach eine grundlegende Trennung zwischen Programmlogik und GUI machen. In der Programmlogik kann man sich dann auch an die normalen Namenskonventionen halten und hat damit so ein bisschen ”Dokumentation” was GUI-Code ist und was nicht. Wenn man einen unkonventionellen Namen in der Programmlogik verwenden muss, weiss man, dass die Trennung nicht sauber ist.

[adenied]

Hi Blackjack,

erst einmal vielen Dank für diese sehr ausführliche Antwort. Dass Python in vielen Punkten "anders" als Java ist, habe ich schon mitbekommen (in Bezug auf private Member, auf die man dann doch von außen zugreifen kann, nicht eine Klasse pro Datei etc.). Im Grunde genommen sagst Du mit Deiner Antwort das, was ich innerlich gehofft habe: "versuch nicht Swing, bzw. eine Swing-Architektur" nachzubauen. Swing ist in vielen Punkten ein riesiges, aufgeblähtes Monster, das ist mir klar. Ich habe es auch schon mehr als einmal verflucht, obwohl ich mich jetzt mal einfach als professionellen (im Sinne von "beruflich") Experten bezeichnen möchte.

Der Grund, warum ich nun privat auf Python umsteigen möchte, liegt in der Lizenzpolitik von Java. Ich bin auch offen für Neues, und die Dinge, die Du in Deiner Antwort beschreibst sind für mich auch erst einmal völlig okay, wenn auch in einigen Punkten sehr ungewohnt

Ich weiß, ich stelle keine konkrete Frage, die man beantworten kann, vermutlich, weil ich die Frage selber nicht kenne. Ich vermute, dass ich gerade ein wenig Hochachtung vor meinem eigenen Mut habe, als erstes Python Programm gleich etwas größeres (Noten-Editor-Programm mit Midi-Ausgabe für Gitarre, eigentlich sowas wie GuitarPro unter Windows) schreiben möchte. Nicht wegen des Programms an sich. In Java hätte ich damit gar kein Problem. Mir geht es darum, dass ich nicht blind in Python anfangen möchte, um dann irgendwann mittendrin zu merken: nee, das ist architektonisch gesehen Mist und jetzt muss ich erstmal das nächste halbe Jahr Refactoring betreiben.

Leider finde ich aber auch keine geeigneten Quellen bzgl. Architektur von Python-Anwendungen. Okay, wenn es in Python eher unüblich ist, eine Interpretation von MVC zu verwenden, gut. Wenn man nicht alles in eine Klasse packt, sondern auch einfach nur Funktionen in einem Modul hat: auch gut. Aber das sind eben genau die "Architekturvorgaben", die mir so ein bisschen fehlen.

[__blackjack__]

“Architektur von Python-Anwendungen” klingt irgendwie etwas hochtrabend. So ganz grundsätzlich ist es da nicht anders als in anderen Programmiersprachen auch. Es gelten die allgemeinen Empfehlungen wie GUI und Geschäftslogik zu trennen und sich an dem zu orientieren was die verwendeten Rahmenwerke vorgeben/empfehlen.

Es ist auch nicht so das man in Python keine MVC-Spielart verwendet, denn das ist keine Frage von Python, sondern von dem verwendeten GUI-Rahmenwerk. Es gibt da ja durchaus welche wie Qt die Model- und View-Klassen anbieten.

Wenn Du für jeden Aspekt ein Enterprise-Rahmenwerk gewohnt bist, in das man als Programmierer den eigenen Code in ein vorgegebenes Gerüst aus Interfaces giesst, statt dem Programmierer viel Freiraum zu lassen, also quasi kein Gerüst und man kann den Code wie Knetgummi formen wie man möchte, dann ist Python mindestens mal gewöhnungsbedürftig.

Gerade beim ersten grösseren Projekt in einer neuen Programmiersprache sollte man meiner Erfahrung nach davon ausgehen, dass man da Teile neu schreibt, wenn man die Sprache besser kennengelernt hat. Man weiss am Anfang halt noch nicht alles, beziehungsweise hat noch keine praktische Erfahrung, und wenn man schon eine andere Programmiersprache kann, deren ”Kultur” nicht wirklich sehr ähnlich ist, wird man sicher am Anfang auch Sachen noch ”javaesque” statt ”pythonisch” lösen.