Sie haben GUI-Klassen, die Anwendungslogik enthalten.
Trennen Sie die Anwendungslogik in separate Klassen ab.
12.6.1 Motivation
Jedes Mal, wenn Fachleute ỹber Objekte reden, hửren Sie etwas von Model-View- Controller (MVC, Beobachtermuster). Diese Idee steckt hinter dem Verhọltnis von grafischer Benutzerschnittstelle (GUI) und den Anwendungsobjekten in Smalltalk-80.
Der wertvolle Kern von MVC ist die Trennung von Benutzerschnittstellencode (der Sicht (view), heute oft als Prọsentation bezeichnet) und der Anwendungslo- gik (dem Modell (model)). Die Prọsentationsklassen enthalten nur die Logik, die notwendig ist, um mit der Benutzerschnittstelle umzugehen. Anwendungsob- jekte enthalten keinen visuellen Code, aber alle Geschọftslogik. Dies trennt zwei komplizierte Programmteile in Stỹcke, die leicht zu ọndern sind. Es ermửglicht
Order Window
➾
Order Window Order
1
mehrere Prọsentationen derselben Geschọftslogik. Wer Erfahrung im Arbeiten mit Objekten hat, verwendet diese Trennung instinktiv, und sie hat ihren Wert bewiesen.
Aber so legen die meisten Entwickler, die mit GUIs arbeiten, ihr Design nicht an.
Die meisten Umgebungen mit Client-Server-GUIs verwenden ein Zweischichten- design: Die Daten liegen in der Datenbank und die Logik in den Prọsentations- klassen. Die Umgebung erzwingt oft diesen Stil und macht es Ihnen schwer, die Logik an anderer Stelle unterzubringen.
Java ist eine richtige objektorientierte Umgebung. Sie kửnnen daher nicht visuelle Anwendungsobjekte erstellen, die Anwendungslogik enthalten. Họufig begegnen Sie aber Code, der in diesem Zweischichtenstil geschrieben ist.
12.6.2 Vorgehen
• Erstellen Sie eine Anwendungsklasse für jedes Fenster.
• Haben Sie eine Tabelle im Fenster, so erstellen Sie eine Klasse für jede Zeile in der Tabelle. Verwenden Sie eine Collection in der Anwendungsklasse des Fens- ters für die Anwendungsobjekte in den Zeilen.
• Untersuchen Sie die Daten im Fenster. Sind sie nur für Aufgaben der Benutzer- schnittstelle da, lassen Sie sie in dem Fenster. Wenn sie in der Anwendungslo- gik verwendet werden, aber nicht im Fenster dargestellt werden, so verwenden Sie Feld verschieben (144), um sie in die Anwendungsklasse zu verschieben.
Wenn die Daten sowohl in der Benutzerschnittstelle als auch in der Anwen- dungslogik verwendet werden, so verwenden Sie Beobachtete Werte duplizieren (190), so dass sie an beiden Stellen vorhanden sind und die Synchronisierung garantiert ist.
• ĩberprỹfen Sie die Prọsentationsklasse. Verwenden Sie Methode extrahieren (106), um die Logik der Prọsentation von der Anwendungslogik zu trennen.
Wenn Sie die Anwendungslogik isoliert haben, verwenden Sie Methode verschie- ben (139) um sie in die Anwendungsklasse zu verschieben.
• Wenn Sie damit fertig sind, haben Sie Prọsentationsklassen, die die GUI hand- haben, und Anwendungsklassen, die alle Anwendungslogik enthalten. Die An- wendungsobjekte werden noch nicht gut faktorisiert sein, aber damit werden sich weitere Refaktorisierungen beschọftigen.
12.6.3 Beispiel
Wir haben hier ein Programm, das es Benutzern ermửglicht, Auftrọge einzugeben und die Preise zu ermitteln. Die GUI sieht aus wie in Abbildung 12-7.
Die Prọsentationsklasse interagiert mit einer relationalen Datenbank, die in Abbil- dung 12-8 dargestellt ist.
Das ganze Verhalten, sowohl das der GUI als auch das Ermitteln der Preise für die Auftrọge, befindet sich in einer Klasse OrderWindow.
Abbildung 12-7 Die Benutzerschnittstelle für das Ausgangsprogramm
Wir beginnen damit, eine geeignete Auftragsklasse Order zu erstellen. Wir verbin- den sie mit dem OrderWindow wie in Abbildung 12-9. Da das Fenster eine Tabelle enthọlt, um die Auftragszeilen anzuzeigen, erstellen wir auch eine Klasse Order- Line für die Zeilen der Tabelle.
Abbildung 12-8 Die Datenbank für das Auftragsprogramm
Abbildung 12-9 Auftragsfenster (Order Window) und Auftrag (Order) Name: Text
CustomerID: Number Codes: Text
Customers
OrderID: Number CustomerID: Number ôFKằ
Amount: Number Orders
OrderID: Number ôFKằ
ProductID: Number ôFKằ
Quantity: Number Amount: Number
OrderLines
ProductID: Number Name: Text Threshold1: Number Price1: Number Threshold2: Number Price2: Number Threshold3: Number Price3: Number Threshold4: Number Price4: Number
Products
1
1
1
All classes are ôSQL Tableằ. Bold attributes show primary key columns.
ôFKằ indicates foreign keys
∗ ∗
∗
Order Window Order
1
Order Line
∗
Wir gehen vom Fenster aus, nicht von der Datenbank. Ein erstes Modell des An- wendungsbereichs auf einer Datenbank aufzubauen ist eine sinnvolle Strategie.
Unser grửòtes Risiko ist hier aber die Vermischung von Prọsentations- und An- wendungslogik. Wir trennen diese auf Basis des Fensters und refaktorisieren den Rest spọter.
Bei dieser Art von Programmen ist es nützlich in den GUI-Klassen, nach eingebet- teten SQL-Befehlen (Structured Query Language) zu suchen. Daten aus einem SQL-Befehl sind Anwendungsdaten.
Das einfachste Anwendungsmodell, mit dem wir arbeiten kửnnen, ist nicht direkt in der GUI zu erkennen. In diesem Fall enthọlt die Datenbank ein Feld Codes in der Tabelle Customer. Dieses Feld wird nicht direkt in dem Fenster angezeigt; es wird in eine fỹr Menschen besser lesbare Form gebracht. Wir kửnnen dieses Feld gefahrlos mittels Feld verschieben (144) in die Anwendungsklasse verschieben.
Mit den anderen Feldern haben wir nicht so viel Glück. Sie enthalten AWT-Kom- ponenten, die in dem Fenster angezeigt und in den Anwendungsobjekten ver- wendet werden. Für diese müssen wir Beobachtete Werte duplizieren (190) einset- zen. Dies fügt ein Anwendungsfeld in die Klasse Order ein, zu dem es ein entsprechendes AWT-Feld im OrderWindow gibt.
Dies ist ein langsamer Prozess, aber am Ende haben wir alle Felder für Anwen- dungslogik in der Anwendungsklasse. Ein guter Leitfaden für diesen Prozess be- steht darin zu versuchen, alle SQL-Befehle in die Anwendungsklasse zu verschie- ben. Sie kửnnen die Datenbanklogik und die Anwendungsdaten gemeinsam in die Anwendungsklasse verschieben. Ob Sie damit fertig sind, kửnnen Sie gut fest- stellen, indem Sie java.sql nicht mehr im OrderWindow importieren. Dies heiòt fỹr Sie, sehr oft Methode extrahieren (106) und Methode verschieben (139) anzuwenden.
Die so entstandenen Klassen in Abbildung 12-10 sind noch weit davon entfernt, gut faktorisiert zu sein. Aber das Modell reicht aus, um die Anwendungslogik ab- zutrennen. Bei dieser Refaktorisierung müssen Sie sehr genau darauf achten, wo Ihre Risiken liegen. Wenn die miteinander verschlungene Prọsentations- und An- wendungslogik Ihr grửòtes Risiko ist, trennen Sie sie vollstọndig, bevor Sie andere Dinge angehen. Sind andere Dinge wichtiger, wie die Preisfindungsstrategien für die Produkte, so ziehen Sie den wichtigsten Teil dieser Logik aus dem Fenster her- aus und refaktorisieren darum herum eine geeignete Struktur für das Gebiet mit dem hửchsten Risiko. Wahrscheinlich muss der grửòte Teil der Anwendungslogik aus der Klasse OrderWindow entfernt werden. Wenn Sie refaktorisieren kửnnen, aber einige Logik im Fenster belassen müssen, so beginnen Sie mit dem Bereich, in dem Ihr Risiko am hửchsten ist.