Autor Thema: Aufbau einer GUI  (Gelesen 3657 mal)

Offline Gandhi

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 918
  • Geschlecht: Männlich
  • Domino for the masses
Aufbau einer GUI
« am: 20.09.03 - 00:10:57 »
ich bereite mich gerade seelisch und mental darauf vor nächste Woche mit deEntwicklung einer Swing-GUI zu beginnen und habe da noch eine Frage zur Vorgehensweise bzw. Struktur.
Die GUI selbst wird ja einíge Elemente wie z.B. Buttons haben. In diesem Zusammenhang habe ich Probleme mit der Zuweisung von EventListenern. Ist es ratsam wie folgt vorzugehen - oder spricht etwas total dagegen?
Ich habe vor für jedes Control eine Subklasse anzulegen, diese von der Swingklasse erben zu lassen und dann die EventListener als Schnittstelle zu implementieren:
Bsp: Class MyButton extends JButton implements ActionListener,
MouseListener,....
Weiterhin möchte ich eine Funktion zum setzen der Constraints in dieser Klasse implementieren.
Ein spezieller Button würde dann von MyButton erben.
Ich hoffe es ist klar, was ich meine....
Was ich mir davon erhoffe ist eine viel bessere Übersichtlichkeit über die
Funktionen der einzelnen Buttons. Was ich befürchte ist vor allem, dass durch
die vielen Listener die Performance absackt.
Daher die Frage, bevor ich Wochen in die falsche Idee stecke: Macht man das so - kann man das so machen?
Zur Info über das Ziel: Das soll eine Gui mit Card Layout (5 Reiter) und insgesamt ca 50 Elementen werden (irgendwann mal....).
Wenn ich da jetzt, wie gelesen mit inneren Klassen rangehe steht dann in einem Script 20 Seiten Text - daher meine Suche nach der übersichtlichen, strukturierten Variante.
Der "Wenn ich" und der "Hätt' ich" das sind zwei arme Leut'
oder für den Süden:
Hatti Tatti Wari - san drei Larifari

Offline Axel_Janssen

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 769
Re:Aufbau einer GUI
« Antwort #1 am: 20.09.03 - 02:10:12 »
... wait a moment...  

Gehe besser von Bekannten aus und versuche nicht die Welt neu zu erfinden.

Eine professionelle Umsetzung von Card-Layout findest du hier:
http://www.jgoodies.com/freeware/looksdemo/index.html
Da ist zwar wieder alles umgestellt, aber da dürfte der Source code von dem demo-Teil, was du da siehst mit im Download sein. Falls nicht melde dich. Du mußt nicht den Form-Layout manager oder die Looks-Look and Feels verwenden (obwohl letzteres sich wohl in jedem Fall anbietet). Es geht darum wie er seine gui strukturiert hat.

Der weiß ziemlich genau, was er tut und der hat die einzelnen Tabs als eigene Klassen und arbeitet auch nicht mit Vererbung sondern gemäß dem 2. heiligsten Satz moderner OO-Theorie:
"favour aggregation over inheritance".

In den Event-Listenern steht normal immer sehr wenig code. Vielmehr kommuniziert der code in den Listenern mit anderen Klassen, die für die Funktionalität zuständig sind (sogenannte Business Objekte).
Eine gute Idee ist immer eine geschichtete Architektur.
Die GUI-Schicht (User-Interaktion) kommuniziert aus den EventListenern mit der Schicht an Business-Klassen, die wiederum mit der Persistenz-Schicht kommunizieren (Klassen die für Speichern in Notes, RDBMS, XML-Dateien, normale Dateien, etc.) zuständig sind.

Tue dir selbst den Gefallen und schaue dir das erst einmal an: http://www-106.ibm.com/developerworks/java/edu/j-dw-javapatt-i.html
Das mag sehr verwirrend sein, besonders Strategy Pattern, aber das mußt du gar nicht alles verstehen.
Begleitend können auch die folgenden Seiten hilfreich sein:

nicht so toll, aber gratis:
http://www.patterndepot.com/put/8/JavaPatterns.htm
für J2EE:
http://www.corej2eepatterns.com/Patterns2ndEd/index.htm

Am einfachsten finde ich folgendes Vorgehen (ist quasi ein Kompromiß aus strukturaler und OO-Programmierung):
Du gliederst die reine Funktionalität der App thematisch.
Für jeden Funktionsbereich baust du eine eigene Business Klasse mit Methoden und Properties.
Das sind dann die Business Objekte, die aus der GUI angesprochen werden
Benutze dafür Singleton und Facade Pattern (IBM Tutorial). Alle Methoden in den Business Objekten, die von der GUI angesprochen werden sind public, die internen private. Die public Methoden bilden das Interface des Business Objekts (nicht zu verwechseln mit Java-Interfaces).
   
Für den Zugriff auf die Datenbank kannst du fürs erste mal auch eine Singleton-Facade (IBM Tutorial) bauen (obwohl es da bessere Möglichkeiten gibt).

Das Swing Event System ist eine ziemlich gute Implementierung des Observer Patterns (IBM Tutorial). Brauchst dir da keine Sorgen zu machen. Gerade die Implementierung als Inner Classes ist vom Performance-Standpunkt sinnvoll. Das sieht vielleicht zwar kompliziert aus, aber du kannst es ja einfach aus dem Buch abtippen.

OO-Design/Architektur ist kein wirklich kreativer Prozeß, sondern mehr ingenieursmässig. Es geht zu einem großen Teil darum reale business cases auf ein Repository an vorhandenen Entwurfsmustern (Design Patterns) zu mappen.

Du stellst Mutmaßungen über Performance-Verhalten an, ohne ausreichend empirische Erfahrungswerte zu haben. Betrachte am besten Performance Tuning erst mal als nicht so wichtig. Später siehst du dann, wo die Performance- Bottlenecks sind. Du spekulierst jetzt darüber, was Performance-Probleme macht.
Das ist so ähnlich als wenn mein ungeborenes Kind als 5 jähriger spekulieren würde, dass die Schwerkraft auf dem Mond stärker als die auf der Erde ist, da man an jedem Punkt der Mondoberfläche näher am Kern ist (kleinerer Radius) und die Schwerkraft ja scheinbar vom Kern ausgeht.

Ich arbeite bei Swing mit dem Swing Buch (2nd Edition) von http://www.manning.com/robinson2/index.html. (kostet 25 Euro als pdf). Da sind die einzelnen Elemente kapitelmäßig aufgeführt. Erst werden alle Klassen und Interfaces beschrieben (reiner Nachschlageteil, man kann das nicht lesen, nur nachschlagen). Danach werden die Beispiele beschrieben (immer mein Ansatzpunkt). Du kannst dir den code von der Manning Seite runterladen. Da gibt es batch-Dateien fürs kompilieren und starten.

Gruß Axel
« Letzte Änderung: 21.09.03 - 10:30:37 von Axel_Janssen »
... design patterns are abstract designs that help identify the structure and elements involved in a specific design solution. From this, a concrete implementation can be produced.
Kyle Brown

Offline Axel_Janssen

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 769
Re:Aufbau einer GUI
« Antwort #2 am: 21.09.03 - 10:28:44 »
O.k. klingt verwirrend.
Werde die Tage ein kleines Beispiel posten.
... design patterns are abstract designs that help identify the structure and elements involved in a specific design solution. From this, a concrete implementation can be produced.
Kyle Brown

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz