Model von UI trennen
Einführung
Code für ein GUI wird sehr schnell unübersichtlich, wenn die Instanziierung und die Logik in einer Klasse untergebracht werden.
Beim implementieren der Logik, nisten sich schnell viele Zeilen Code mit Details und Listener ein. Dies erschwert die Übersicht auf den Code erheblich.
Das nächste Problem ist, dass sich die Komponenten gegenseitig Werte und Zustände zu jonglieren. Genau diese Informationen können abstrahiert und in eine neue Klasse ausgelagert werden.
Diese Logik wird auch als Model bezeichnet. Jede Swing-Komponente besitzt bereits seit ihrer Instanziierung ein Standard-Model. In den meisten Fällen wird das Model gar nicht direkt verwendet - geschweige dem, dass ein eigenes Model für die Komponente erstellt wird.
Ein eigenes Model zu erstellen hat allerdings seine Vorteile:
Beim implementieren der Logik, nisten sich schnell viele Zeilen Code mit Details und Listener ein. Dies erschwert die Übersicht auf den Code erheblich.
Das nächste Problem ist, dass sich die Komponenten gegenseitig Werte und Zustände zu jonglieren. Genau diese Informationen können abstrahiert und in eine neue Klasse ausgelagert werden.
Diese Logik wird auch als Model bezeichnet. Jede Swing-Komponente besitzt bereits seit ihrer Instanziierung ein Standard-Model. In den meisten Fällen wird das Model gar nicht direkt verwendet - geschweige dem, dass ein eigenes Model für die Komponente erstellt wird.
Ein eigenes Model zu erstellen hat allerdings seine Vorteile:
- Mehr Kontrolle und Übersicht auf die Zustände der Komponente
- Das Model ist unabhängig vom GUI
- Besseres Verständnis für die Komponente ansich
Model Klassen
In folgender Liste findet man die Komponenten und ihre Model-Klasse. Wie man erkennt ist, sind die Namingkonventions der Model-Klassen leider nicht immer gleich.
| GUI-Komponente |
Model (Type) |
Model (Type mit höherer Abstrakion) |
| JTextField |
PlainDocument |
|
| JComboBox |
DefaultComboBoxModel | ComboBoxModel |