$K(Benutzungsoberläche)

$KK(Trennung Interaktion und Funktionalitätskomponente)

Zur Einführung ein abschreckendes Beispiel aus einem realen Projekt 
 
$B(Bilder,dokliste.gif,Ein abschreckendes Beispiel) 
 
Hier das entsprechende Objektmodell: 

$B(Bilder,dokmod.gif,Direkte Verbindung von UI zur Domain Schicht)
 
Diese Lösung erzeugt einige Probleme: 

* Der Kernel des UI-Objekts wechselt, jenachdem welches Dokument selektiert ist. 
* Falls gerade kein Dokument selektiert ist, ist der kernel nil 
* Sind mehrere Dokumente selektiert, was ist der Kernel? 
* Bei jedem Aufruf der Operation ist eine Fallunterscheidung notwendig; ob mehrere, genau ein oder kein Dokument selektiert ist 
* Die Funktionen zum Neuanlegen eines Objekts, und alle andere Operationen, die sich nicht auf das selektierte Dokument beziehen, müssen zwangsläufig in der UI-Schicht realisiert werden. 

Hier ein besserer Design: 

$B(Bilder,dokmod1.gif,Trennung Interaktion und Funktion)

<u>Merke:</u> Teile ein darzustellendes Fenster in eine Interaktion und Funktionskomponente auf.

Ich selbst habe mir beim Design folgende Regeln auferlegt: 

* Jedem Interaktionskomponente ist genau eine Funktionskomponente zugeordnet, 
umgekehrt kann ein Funktionskomponente, mehrere oder keine Interaktionskomponente zugeordnet sein. 
* Das Interaktionskomponente kennt seine Funktionskomponente (feste Kopplung) i.a. über eine Instanzvarialble. 
* Funktionskomponenten kennen ihre Interaktionskomponenten nicht (direkt). (siehe lose Kopplung mit Hilfe des Beobachter Patterns) 
* Interaktionen finden nur in den Interaktionskomponenten statt (d.h Interaktionskomponenente enthält nur Widgets) 
* Die Domain Objekte hängen an der Funktionskomponente. 

$KK(Bildung komplexer Fenster aus einfachen)

Oft werden komplexe Fenster, modular aus einfacheren Fenster zusammengebaut. 
Ein typischens Beispiel dafür sind Notebooks; jenachdem welchen Reiter man anwaehlt ist ein 
anderes Subfenster aktiv. Ein Subfenster kann wiederum aus mehreren Subfenstern bestehen. 
So entsteht ein Baum von Fenstern. 

Ich empfehle folgende Richtlinien beim Bau komplexer Fenster: 


* Jedes (Unter-)Fenster soll als eigenständiges Fenster, entwickelt und getestet werden. 
* Entwickle zuerst die Unterfester, teste die Funktionalität und entwickle und teste zuletzt das oberste Fenster 
* Jedes (Unter-) Fenster besteht aus einer Interaktions- und aus einer Funktionskomponente
* Jedes Fenster kennt seine direkten Unterfenster (über eine Instanzvariable). 
** Eine Funktionskomponente eines Fensters kennt seine Funktionskomponenten der direkten Unterfenster
** Eine Interaktionskomponente eines Fensters muss nicht aber kann die Interaktionskomponente der direkten Unterfenster kennne. 
* Die Funktionskomponente eines Unterfensters kennt die Funktionskomponente des übergeordneten Fensters nicht direkt. Kommunikation erfolgt mit Hilfe des Beobachterpatterns 
* Eine Fenster koordiniert seine (nur)die direkten Unterfenster. Eine Interaktion im Fenster hat eine der folgenden Auswirkungen: 
** Es wird im Kernel Objekt des Fensters eine Aktion ausgeloest 
** Die Interaktion wird an einen oder mehrere der Unterfenster delegiert. 
** Ggf. wird in Unterfenstern eine andere Interaktion als die im Oberfenster aufgetretene ausgelöst. 

Siehe dazu die Abbildung aus dem objektorientierten Konstruktionshandbuch. IAK bedeudet dabei Interaktionskomponente und entspricht den eigentlichen Fensterobjekten. FK bedeudet Funktionskomponenten.
Gestrichelte Linien kennzeichnen indirekte Kommunikation über Beobachter Pattern.

$B(Bilder,kompfens.gif,Struktur komplexer Fenster)