$KK(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.
$KKK(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.
$KKK(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
$R(Definition>begriff=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.
$R\
$R(Literatur)
[i|OO Konstruktionshandbuch>oo-konstruktion] Kapitel 2.1.9: Modularisierung
$R\
$KKK(Prinzipien des Paket Designs)
Robert C. Martin hat folgende Package Design Regeln veröffentlicht. Man wird allerdings wohl
nie alle Prinzipien leichzeitig benutzen können.
The Release Reuse Equivalency Principle (REP)
Füge Klassen die gemeinsam benutzt werden, bzw. gemeinsam freigegeben werden in ein Paket
The Common Closure Principle CCP
Füge Klassen die gemeinsam für eine Sache verantwortlich sind in ein Paket
The Common Reuse Principle CRP
Trenne Klassen die von verschiedenen Klienten benutzt werden, in verschiedene Pakete.
The Acyclic Dependencies Principle ADP
Vermeide unbedingt Zyklen zwischen den Abhängigkeiten von Paketen. Für Java Programmierer
hilft hier ein hervorragendes Open-Source Tool [e|JDepend>http://www.clarkware.com] dies zu
vermeiden.
The Stable Dependencies Principle SDP
Wenn Paktet A von Paket B abhängig ist, dann sollte Paket B stabiler gegenüber Änderungen sein
als Paket A. Das schon erwähnte Tool [e|JDepend>http://www.clarkware.com] benutzt Metriken um
die Stabilität eines Pakets zu messen.
The Stable Abstractions Principle SAP
Ein Paket bei denen Änderungen aufwendig sind, sollte nicht von einem Paket abhängig sein, bei dem
Änderungen sehr einfach möglich sind.
$R(Literatur)
[i|OO The Principles, Practices and Patterns of Agile Software Development>ppp]
$R\