Um direkt zu meiner Frage zu kommen.
Wie machen Sie große GUI-Projekte? Ich habe bisher noch keine größeren GUI-Projekte in Java gemacht, aber woran ich gerade arbeite, ist jetzt ziemlich schnell und ziemlich groß geworden und jetzt stecke ich mit einem riesigen Haufen Code fest, der wirklich nervig und unordentlich ist.
Da ich aus dem Bereich der Webentwicklung komme, bin ich an MVC-Frameworks gewöhnt, so habe ich 3 Pakete in meinem Projektmodell, wo ich Klassen halte, die mit Dateien oder db interagieren, Ansichten, wo ich meine Klassen für Formulare oder GUI und Controller-Paket aufbewahre wo ich die Mehrheit meiner Logik behalte.
Mir wurde gesagt, ich solle meine Logik trennen und Aktionen in einer Klasse und Zuhörer in einer anderen Klasse halten, aber ich habe keine Ahnung, wie ich das alles verknüpfen soll.
Bis jetzt habe ich nur 1 Controller-Klasse, wo ich alle Methoden in Bezug auf was passiert auf der GUI einmal ausgeführt wird ausgeführt.
%Vor%Es gibt viele Tutorials und Beispiele, wie man kleine Java-GUI in der Regel mit einer einzigen Klasse macht, aber keine Tutorials oder Beispiele, wie man Projekte ausführt, die etwas größer sind als eine einzelne Klasse.
Vielen Dank im Voraus für die Hilfe und Beratung.
Hier ist mein Rat für die Swing-Entwicklung im Allgemeinen. Es wird diskutiert, wie wichtig es ist, Controller zu verwenden, um die Bedürfnisse der Ansicht und der Interaktion des Modells zu überbrücken.
Letztes Swing-Projekt Ich habe ein MVC-Framework entworfen, das Spring für die Definition des Modells des Programms und der Controller verwendet hat und dann Annotationen im Controller verwendet hat, um Ereignisse, die von der Ansicht an Methoden im Controller gesendet wurden, zu verkabeln. Die Ansicht hatte Zugriff auf den Ereignis-Dispatcher, der ein Ereignis-Bus war, und Ereignisse, die über den Bus gesendet wurden, und Methoden auf dem Controller durch die Anmerkungen aufgerufen. Dadurch konnte jeder Controller auf Ereignisse aus der Ansicht reagieren. Als ein Controller zu groß wurde, war es sehr einfach, jeden Methodensatz in einen anderen Controller umzuwandeln, und die Ansicht oder das Modell mussten sich nicht ändern.
Die Schönheit des Ereignisbusses war, dass es auch mit dem Modell geteilt werden konnte, so dass das Modell asynchrone Ereignisse senden konnte, für die sich der Controller registrieren konnte. Es sah ungefähr so aus:
%Vor%Sobald dieser Rahmen vorhanden war, war es erstaunlich, wie schnell wir die Dinge erledigen konnten. Und es hat ziemlich gut gehalten, als wir Features hinzugefügt haben. Ich habe meinen Anteil an großen Swing-Projekten (3 bis heute) gemacht, und diese Architektur hat einen großen Unterschied gemacht.
Die einfachste Möglichkeit, eine GUI zu skalieren, besteht darin, alles lose miteinander zu verbinden. Events (Swing und deine eigenen) sind der beste Weg, dies zu tun. Wenn eine Klasse kein GUI-Element direkt erstellt oder anzeigt, sollte sie nichts anderes auf der Benutzeroberfläche kennen oder interessieren.
Der Controller sollte weiter machen, was er tun soll - Ereignisse als Reaktion auf andere Ereignisse auslösen. Diese Ereignisse sollten jedoch Ereignisse auf Anwendungsebene sein, die von den Anforderungen Ihrer App definiert werden. Der Controller sollte GUI-Elemente nicht direkt manipulieren. Stattdessen sollten Sie Komponenten erstellen (möglicherweise nur Unterklassen von JWhatever), die sich bei der Steuerung als an Ereignissen interessiert registrieren.
Erstellen Sie zum Beispiel eine TowerEventListener -Schnittstelle mit einer nameChanged() -Funktion. Der Controller hat auch eine Funktion changeTowerName() , die bei Aufruf das Modell aktualisiert (eine Tower-Klasse) und dann nameChanged() für alle registrierten TowerEventListeners aufruft.
Erstellen Sie dann eine TowerRenamer-Klasse, die beispielsweise JDialog-Unterklassen (d. h. ein Popup-Fenster) enthält, die ein Textfeld und die Schaltfläche OK sowie einen Verweis auf den Controller enthalten. Wenn der Benutzer auf OK klickt, wird Controller.changeTowerName() aufgerufen. Andere Teile Ihrer GUI, die sich als TowerEventListeners registrieren, erhalten das Ereignis und werden bei Bedarf aktualisiert (z. B. indem Sie ein JLabel auf der Benutzeroberfläche aktualisieren).
Hinweis: Wenn Ihre Anforderungen einfach genug sind, können Sie einfach PropertyChangeEvents verwenden und sich keine Sorgen über die gesamte Struktur der Ereignisschnittstelle machen. PropertyChangeSupport kann vom Controller verwendet werden, um Ereignisbenachrichtigungen auszulösen.
Zusätzlich zu den großartigen Ratschlägen, die ich bereits gegeben habe, würde ich empfehlen, etwas zu lesen, was Trygve Reenskaug geschrieben hat und / oder aufgenommen auf seiner MVC-Seite . Er war dort während der Entwicklung dieses architektonischen Stils in den späten 70er Jahren. Sein zweiseitiger technischer Bericht mit dem Titel Modelle - Ansichten - Controller vom Dezember 1979 stellt die prägnanteste Beschreibung des Modells, der Ansicht und des Controllers vor.
Von besonderer Bedeutung sind Ansichten sowohl Beobachter als auch Manipulatoren des Modells. Der Controller befasst sich hauptsächlich damit, die Ansichten anzuordnen (zu verdrahten) und Benutzereingaben in Interaktionen mit dem Modell zu übersetzen. Einige der MVC-Frameworks da draußen haben Controller, die Daten vom Modell zur Ansicht weiterleiten - das ist einfach falsch. Ein Papier von früher 1979 enthielt das Konzept eines Editor als eine Zusammenstellung verwandter Ansichten. Der Editor wurde verworfen; Die Funktionalität wurde sowohl in den Controller als auch in die Ansicht verschoben.
Ein anderer Artikel, der gut beschreibt, wie man diese Richtlinie anwendet, ist
Ich denke, dass das Wichtigste ist, dass der ursprüngliche MVC-Stil für Benutzerschnittstellen erstellt wurde, die mehr als eine Ansicht (Darstellung) desselben Modells enthielten. Dies funktioniert wirklich gut für Benutzeroberflächen, aber nicht besonders gut in die Web-Service-Welt übersetzen. Mit MVC für eine GUI können Sie wirklich die Macht dieses Stils sehen und verstehen.
Tags und Links java user-interface swing