Bitte beachten Sie, dies ist ein langer Post. Entschuldigung, aber ich möchte klarstellen:
Ich habe mich gefragt, wie man Swing GUI von Presentation und Business Logic für eine ziemlich lange Zeit trennt. Bei der Arbeit musste ich einen 3-MD-Excel-Export für einige Daten mit einem kleinen Swing-Dialog implementieren, um den Export zu konfigurieren. Wir verwenden dafür kein Framework wie Spring, also musste ich es selbst implementieren.
Ich wollte die GUI von Business Logic vollständig trennen, was genau die folgenden Aufgaben sind:
Natürlich sollte die GUI die BL-Implementierung nicht bemerken und umgekehrt.
Ich habe mehrere Schnittstellen für alle oben genannten Aufgaben geschaffen, z. G. a ProgressListener , LogMessageListener , JobDoneListener ,
usw., die von der Business Logic ausgelöst werden. Wenn die Business-Logik beispielsweise über die Protokollierung informieren möchte, ruft sie
Klassen, die die öffentliche Schnittstelle LogListener + implementieren, werden an die BL angehängt, jetzt wird über die Protokollmeldung "Job wurde gestartet" benachrichtigt. Alle diese Listener werden zu diesem Zeitpunkt von der GUI selbst implementiert, die im Allgemeinen so aussieht:
%Vor%Die "GUI and BL creating class" fügt einfach die GUI (wie alle diese Listener-Schnittstelle) an die BL an, die in etwa so aussieht:
%Vor%Ich bin mir jetzt ziemlich unsicher, weil es wegen all dieser neu erstellten Listener-Interfaces seltsam aussieht. Was denkst du über? Wie trennst du deine Swing-GUI-Komponenten von BL?
Bearbeiten: Zur besseren Veranschaulichung habe ich einen Demo-Arbeitsbereich in eclipse file-upload.net/download-9065013/exampleWorkspace.zip.html erstellt Ich habe es auch in pastebin eingefügt, aber importiere diese Klassen besser in eclipse, ziemlich viel Code Ссылка
Ein paar Dinge.
Ich hätte den uiDialog-Code in der ExportFunction-Klasse nicht. Die gesamte Perform-Methode sollte nur Code in der Hauptklasse sein. Die Aufgabe von ExportFunctions besteht darin, "zu exportieren" und nicht "zu zeigen".
%Vor%(Swing.invokeLater () wird nicht benötigt)
Sie scheinen ein gutes Stück übertrieben zu sein. Ich weiß nicht, warum du erwarten würdest, dass viele Threads gleichzeitig laufen. Wenn Sie die Taste drücken, würden Sie nur erwarten, dass ein Thread richtig läuft? Dann wäre kein Array von actionPerformedListener erforderlich.
statt dessen:
%Vor%warum nicht einfach:
%Vor%Auf diese Weise können Sie ExportFunction loswerden, die eigentlich keinen Zweck erfüllt.
Sie scheinen viele Listen von Zuhörern zu haben. Wenn du sie nicht wirklich brauchst, würde ich mich nicht darum kümmern und es so einfach wie möglich halten.
Anstelle von:
%Vor%Habe einfach:
%Vor%wo log ist:
%Vor%Auf diese Weise halten Sie es einfacher und sauberer.
GUI sollte nicht über BL wissen, aber BL muss der GUI irgendwie sagen, was zu tun ist. Sie können ad infinitum mit vielen Schnittstellen abstrahieren, aber in 99,99% der Anwendungen ist dies nicht notwendig, besonders bei Ihnen, was ziemlich einfach erscheint.
Also, während der Code, den Sie geschrieben haben, ziemlich gut ist, würde ich versuchen, die Schnittstellen zu vereinfachen und zu reduzieren. Es garantiert nicht so viel Technik.
Grundsätzlich scheint Ihre Architektur in Ordnung zu sein. Ich nehme an, du fragst dich, ob es wegen der zahlreichen Zuhörer ist, die du aufgebaut hast.
Eine Lösung dafür könnte entweder sein:
a) um eine generische Event-Klasse mit Unterklassen für bestimmte Ereignisse zu haben. Sie könnten einen Besucher verwenden, um die tatsächlichen Listener zu implementieren.
b) um einen Event Bus zu benutzen (siehe zum Beispiel Guava). Mit einer Event-Bus-Architektur veröffentlicht Ihr Modell Ereignisse im Event-Bus, und Ihre UI-Objekte werden auf Ereignisse vom Ereignisbus warten und sie filtern.
Einige Systeme können sogar Anmerkungen zum Deklarieren von Listener-Methoden verwenden.
Tags und Links java swing oop decoupling cohesion