... 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.htmlDa 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.htmlDas 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.htmfü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