GRASP
aus Wikipedia, der freien Enzyklopädie
GRASP (General Responsibility Assignment Software Patterns) bezeichnet eine Menge von Entwurfsmustern, mit denen die Zuständigkeit bestimmter Klassen objektorientierter Systeme festgelegt wird.
Sie beschreiben also allgemein welche Klassen und Objekte wofür zuständig sein sollten. Alle diese Regeln sind schon lange bekannt, sie wurden von Craig Larman einfach systematisch beschrieben. Dies erleichtert die Kommunikation zwischen Softwareentwicklern und erleichtert Einsteigern das Entwickeln eines Bewusstseins für guten bzw. schlechten Code.
Inhaltsverzeichnis |
[Bearbeiten] Information Expert
Gib Verantwortlichkeit dem Informations-Experten, d.h. der Klasse, welche die notwendigen Informationen besitzt, um die Verantwortung wahrzunehmen. Beispiel: Eine Klasse Kreis, die die Methode berechneFläche() hat, die aus dem privaten Attribut Radius die Fläche berechnet. Negativ-Beispiel: Eine Klasse berechneFläche, die eine Methode hat, die eine geometrische Form entgegennimmt und deren Fläche berechnet. Im Unterschied zur realen Welt, in der ein Kreis gar nichts macht, muss in der objektorientierten Welt das Objekt alle Methoden besitzen, die Aktionen definieren, die mit ihm gemacht werden können. Auch bekannt als „Do it Myself“ Strategie (Peter Coad). Information Expert ist das grundlegende Prinzip von Objektorientiertem Design und kann auch als Kapselung von Daten bezeichnet werden. Die konsequente Verwendung führt zu geringer Kopplung (low coupling) und hoher Kohäsion (high cohesion).
[Bearbeiten] Creator
Das Erzeuger-Prinzip legt fest, wer eine Instanz einer Klasse (Objekt) erzeugen sollte. Neue Objekte der Klasse A sollten von B erzeugt werden, wenn:
- B eine Aggregation von A ist
- B A-Objekte enthält
- B A-Objekte erfasst
- B A-Objekte mit starker Kopplung verwendet
- B die Initialisierungsdaten für A hat (d.h. B ist Experte bezüglich Erzeugung von A)
[Bearbeiten] Controller
Der Controller (Steuereinheit) bestimmt wer die Systemereignisse verarbeitet, die für eine nicht Benutzeroberflächenklasse bestimmt sind und beinhalten das Domänenwissen.
Es gibt hier zwei Möglichkeiten. Die Verwendung von Use Case-Controllern oder Facade-Controllern. Bei Use Case-Conrollern werden alle Ereignisse eines Use Cases in einer Klasse behandelt. Mini Use Cases können auch in einem Controller behandelt werden, zum Beispiel das erzeugen und löschen eines Users. Wichtig ist einfach, dass die Kohäsion des Controllers möglichst groß ist. Der Facade Controller wird in Message Handling Systemen verwendet, da hier alle Systemereignisse an einem Ort eintreffen. Hier wird ein einziger Controller (MessageHandler) definiert, der alle Ereignisse abfängt. Hierzu wird mit dem Command Pattern gearbeitet.
[Bearbeiten] Low Coupling
Geringe Kopplung ist eins der Hauptziele von gutem Design. Kopplung bezeichnet hier das Mass für die Abhängigkeit eines Elementes (z.B. einer Klasse) von der Umgebung (z.B. von anderen Klassen). Die Hauptvorteile sind dabei die folgenden:
- leichte Anpassbarkeit, da Änderungen in einer Klasse keine Änderungen in anderen Klassen nach sich ziehen
- Verständlichkeit der Klasse, da der Kontext nicht betrachtet werden muss
- gute Testbarkeit
- hohe Wiederverwendbarkeit
[Bearbeiten] Formen von Kopplung
Am Beispiel von der Klasse X zur Klasse Y:
- X ist direkte oder indirekte Unterklasse von Y
- X implementiert das Interface von Y
- X hat Attribut bzw. Referenz von Typ Y (Aggregation/Assoziation)
- X hat Methode, die Y referenziert (Abhängigkeit)
[Bearbeiten] Factory
Das Fabrikmuster wird eingesetzt, wenn beim Erzeugen von Objekten spezielle Logik notwendig ist. Dazu gibt es eine Fabrik-Klasse, das die Objekterzeugung übernimmt und das Objekt zurückliefert.
[Bearbeiten] High Cohesion
Hohe Kohäsion ist vor allem wichtig, um die Komplexität von Klassen zu begrenzen. Die Kohäsion ist ein Maß für den inneren Zusammenhalt einer Klasse. Das heißt sie misst, wie eng die Methoden und Attribute einer Klasse zusammenarbeiten. Ein Negativ-Beispiel wäre z.B. eine Klasse, die Methoden zwei völlig verschiedene Gebiete anbietet. Solche Klassen sind meistens schnell durch völlig nichtssagende Namen und viele Methoden/Codezeilen zu orten.
[Bearbeiten] Zusammenhang High Cohesion / Low Coupling
Hohe Kähesion führt zu geringer Kopplung. Hohe Kähesion und geringe Kopplung ergänzen sich.
[Bearbeiten] Polymorphismus
Polymorphismus kann verwendet werden um das Verhalten abhängig vom Typ zu ändern. Somit können viele Fallunterscheidungen vermieden werden. Besser bekannt ist das Pattern als Strategy GoF
[Bearbeiten] Pure Fabrication
Eine Pure Fabrication (reine Erfindung), stellt eine Klasse dar, die so nicht in der Problem Domain existiert. Sie stellt eine Methode zur Verfügung, für die Sie nicht Experte ist. Normalerweise wird eine Pure Fabrication verwendet, um einen Algorithmus zu kapseln, der in keine Domain-Klasse passt. Sie kann zum Beispiel verwendet werden, um Technologiewissen von Domänenwissen zu trennen. Sie implementiert reines Verhalten und hat somit keinen Zustand. Sollte nicht zu häufig verwendet werden, sonst existieren am Schluss nur noch Klassen die einzelne Methoden kapseln.
[Bearbeiten] Indirection
Indirection (Umweg) kann verwendet werden um geringe Kopplung zu erreichen. Sie wird erreicht, indem ein Vermittler zwischen Client und Server eingebaut wird. Sinnvoll wenn sich ein Serverobjekt ständig verändert. Als Nachteil ist die Leistungsfähigkeit vermindert.
[Bearbeiten] Literatur
- Mark Grand: Patterns in Java. 2 Auflage. John Wiley & Sons, 1999, ISBN 0471258415 (Auszug zum Thema GRASP; Stand: 14. Februar 2007).
