3.2 Pakete

Die Entscheidung welche Klassen in welche Pakete zusammengefasst werden ist nicht trivial. Im folgenden werden einige Aspekte bzw. Regeln zusammengefasst. Man wird allerdings nie alle Regeln gleichzeitig einhalten können.

3.2.1 Horizontale und Vertikale Paket Bildung

Oft habe ich eine horizontale Paket Bildung gesehen. Die Persistenzschicht, die Klassen mit dem Business Objekten und die Präsentationsschicht sind in eigenen Paketen. Wenn man die verschiedenen Schichten auf verschiedenen Servern laufen lassen möchte, ist dies auch sinnvoll. Ich sehe den Nachteil dass man meisten auch bei kleinen Änderungen in allen Schichten eingreifen muss. Ist z.B: die Anforderung einer Person das Attribut E-Mail Adresse hinzuzufuegen, wird meistens das Domain Objekt Person geändert, auf der Datenbank in der Tabelle eine entsprechende Spalte eingefuegt, und die E-Mail Adresse an der Oberfläche angezeigt.

Eine vertikale Paket Bildung ordnet die Klassen die fachlich zusammengehören in ein Paket. So wären die Oberflächen Elemente einer Person, die Datenbank Mapping Klassen, und das Domain Objekt im selben Paket. Dies hat die Vorteil dass sich eine Änderung wahrscheinlich nur in einem Paket auswirkt. Der Nachteil ist das diese Paketbildung es erschwert die Oberfläche bzw. die Datenbank auf einem eigenen Server auszulagern; oder vielleicht die Oberfläche bzw. Datenbank auszutauschen.

Eine Kombination von vertikale und horizontale Paketbildung kann zu einer Vielzahl von Paketen führen.

3.2.2 Kriterien die Pakete erfüllen sollen

Es gibt Metriken, die die Kohäsion und Kopplung messen, allerdings sind diese Berechnungen entweder kompliziert oder wenig brauchbar.

Schon etwas praktischer sind folgende Kriterien die eine Konstuktionseinheit (Paket) erfüllen soll, aus dem Objektorienterten Konstruktionshandbuch:

• Zerlegbarkeit: Ein Entwurfsproblem sollte sich in kleinere, weniger komplexe Teilprobleme zerlegen lassen, die entsprechend als Entwurfs- und Konstruktionseinheiten abgebildet werden. Diese sollten eine einfache Struktur bilden und weitgehend unabhängig konstruiert werden können.
• Kombinierbarkeit: Die Entwurfs- und Konstruktionseinheiten sollten sich durch einfache Rekombination zu neuen Softwaresystemen in verschiedenen Anwendungsbereichen zusammen-fügen lassen.
• Verständlichkeit: Jede Entwurfs- und Konstruktionseinheit eines Softwaresystems sollte weitgehend unabhängig von den anderen verständlich sein.
• Kontinuität: Eine Änderung des Entwurfsproblems, die aus dem Anwendungsbereich oder dem technischen Kontext eines Softwaresystems resultiert, sollte Änderungen nur in einer oder wenigen Entwurfs- und Konstruktionseinheiten erfordern. Um diese Kriterien erfüllen zu können, müssen wir folgende Regeln beachten:
• Direkte Abbildung: Die Struktur des Softwaresystems sollte im engen Zusammenhang mit den im Anwendungsbereich identifizierten Strukturen stehen.
• Wenige Schnittstellen: Jede Entwurfs- und Konstruktionsein-heit sollte mit möglichst wenig anderen interagieren.
• Kleine Schnittstellen: Wenn zwei Entwurfs- und Konstruktionseinheiten interagieren, sollten sie so wenig Information wie möglich und nötig austauschen.
• Explizite Schnittstellen: Wenn zwei Entwurfs- und Konstruktionseinheiten interagieren, sollte dieser Austausch explizit sein.
• Geheimnisprinzip: Nur relevante Merkmale einer Entwurfs-und Konstruktionseinheit sollten für Klienten sichtbar und zugänglich sein.
• Offen-Geschlossen-Prinzip: Entwurfs- und Konstruktionsein-heiten sollten sowohl offen als auch geschlossen sein

Offen-Geschlossen-Prinzip Eine Entwurfs- oder Konstruktionseinheit ist offen, wenn sie weiterentwickelt werden kann. Eine Entwurfs- oder Konstruktionseinheit ist geschlossen, wenn sie stabil von Klienten verwendet werden kann.