https://wiki-de.moshellshocker.dns64.de/index.php?action=history&feed=atom&title=GRASPGRASP - Versionsgeschichte2026-05-26T20:08:16ZVersionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale KopieMediaWiki 1.43.8https://wiki-de.moshellshocker.dns64.de/index.php?title=GRASP&diff=910586&oldid=previmported>Crazy1880: sohin2024-03-08T18:28:37Z<p>sohin</p>
<p><b>Neue Seite</b></p><div>'''GRASP''' (''General Responsibility Assignment Software Patterns'') bezeichnet in der [[Softwaretechnik]] eine Menge von [[Entwurfsmuster]]n, mit denen die Zuständigkeit bestimmter [[Klasse (Objektorientierung)|Klassen]] objektorientierter Systeme festgelegt wird.<br />
<br />
Sie beschreiben also allgemein, welche Klassen und Objekte wofür zuständig sein sollten.<br />
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.<br />
<br />
== Information Expert ==<br />
Gibt dem ''Informations-Experten'' die Verantwortlichkeit, d.&nbsp;h. der Klasse, welche die notwendigen Informationen besitzt,<br />
um die Verantwortung wahrzunehmen.<br />
Beispiel: Eine Klasse ''Kreis'', die die Methode ''berechneFläche()'' hat, die aus dem privaten Attribut ''Radius'' die Fläche berechnet.<br />
Negativ-Beispiel: Eine Klasse ''berechneFläche'', die eine Methode hat, die eine geometrische Form entgegennimmt und deren Fläche berechnet.<br />
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.<br />
<br />
Auch bekannt als „Do it Myself“ Strategie (Peter Coad).<br />
Information Expert ist das grundlegende Prinzip von Objektorientiertem Design und kann auch als Kapselung von Daten bezeichnet werden. Die konsequente Verwendung führt zu loser Kopplung (loose coupling) und hoher Kohäsion (high cohesion).<br />
<br />
== Creator ==<br />
Das ''Erzeuger''-Prinzip legt fest, wer eine Instanz einer Klasse (Objekt) erzeugen sollte. Neue Objekte der Klasse B sollten von A erzeugt werden, wenn:<br />
* A eine [[Aggregation (Informatik)|Aggregation]] von B ist<br />
* A B-Objekte enthält<br />
* A B-Objekte erfasst<br />
* A B-Objekte mit starker Kopplung verwendet<br />
* A die Initialisierungsdaten für B hat (d.&nbsp;h. A ist Experte bezüglich Erzeugung von B)<br />
<br />
== Controller ==<br />
Der ''[[Model View Controller#Steuerung (controller)|Controller]]'' (Steuereinheit) beinhaltet das Domänenwissen und definiert, wer die für eine Nicht-Benutzeroberflächen-Klasse bestimmten Systemereignisse verarbeitet.<br />
<br />
Es gibt hier zwei Möglichkeiten. Die Verwendung von [[Use Case|Use-Case]]-Controllern oder Fassade-Controllern.<br />
Bei Use Case-Controllern 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 nur, dass die [[Kohäsion (Informatik)|Kohäsion]] des Controllers möglichst groß ist.<br />
Der [[Fassade (Entwurfsmuster)|Fassade]]-Controller wird in Message Handling Systemen verwendet, da hier alle Systemereignisse an einem Ort eintreffen.<br />
Hier wird ein einziger Controller (MessageHandler) definiert, der alle Ereignisse abfängt. Hierzu wird mit dem [[Command Pattern]] gearbeitet.<br />
<br />
== Low Coupling ==<br />
''Geringe [[Kopplung (Softwareentwicklung)|Kopplung]]'' ist eines der Hauptziele von gutem Design. Kopplung bezeichnet hier das Maß für die Abhängigkeit eines Elementes (z.&nbsp;B. einer Klasse) von der Umgebung (z.&nbsp;B. von anderen Klassen). Die Hauptvorteile sind dabei die folgenden:<br />
* leichte Anpassbarkeit, da Änderungen in einer Klasse keine Änderungen in anderen Klassen nach sich ziehen<br />
* Verständlichkeit der Klasse, da der Kontext nicht betrachtet werden muss<br />
* gute Testbarkeit<br />
* hohe Wiederverwendbarkeit<br />
<br />
=== Formen von Kopplung ===<br />
''Am Beispiel von der Klasse X zur Klasse Y:''<br />
* X ist direkte oder indirekte Unterklasse von Y<br />
* X implementiert das Interface von Y<br />
* X hat Attribut bzw. Referenz von Typ Y (Aggregation/Assoziation)<br />
* X hat Methode, die Y referenziert (Abhängigkeit)<br />
<br />
== High Cohesion ==<br />
''Hohe [[Kohäsion (Informatik)|Kohäsion]]'' ist vor allem wichtig, um die Komplexität von Gesamtsystemen zu begrenzen, indem man Klassen gut überschaubar organisiert. 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.<br />
<br />
Ein Negativ-Beispiel wäre z.&nbsp;B. eine Klasse, die Methoden aus zwei völlig verschiedenen Gebieten anbietet. Solche Klassen sind meistens schnell durch völlig nichtssagende Namen und viele Methoden/Codezeilen zu orten.<br />
<br />
=== Zusammenhang High Cohesion / Low Coupling ===<br />
Hohe Kohäsion innerhalb der Softwareeinheiten in einem System führt tendenziell zu geringer Kopplung zwischen den beteiligten Softwareeinheiten.<br />
<br />
== Polymorphismus ==<br />
[[Polymorphie (Programmierung)|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 Pattern|Strategy]] ([[Entwurfsmuster (Buch)|GoF]]).<br />
<br />
== Pure Fabrication ==<br />
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.<br />
<br />
== Indirection ==<br />
Indirection (''Umweg'') kann verwendet werden, um geringe Kopplung zu erreichen. Sie wird erzielt, indem ein Vermittler zwischen Client und Server eingebaut wird. Sinnvoll wenn sich ein Serverobjekt ständig verändert. Als Nachteil ist die verminderte Leistungsfähigkeit zu berücksichtigen.<br />
Beispielhaft für dieses Muster ist die Einführung der Controller-Komponente, die zwischen dem Datenmodell (Model) und dessen Präsentation (View) im [[Model View Controller|Model-View-Controller]]-[[Architekturmuster]] vermittelt.<br />
<br />
== Protected Variations ==<br />
Interfaces sollen immer verschiedene konkrete Implementierungen verstecken. Man nutzt also Polymorphismus und Delegation, um zwischen den Implementierungen zu wechseln. Dadurch kann das restliche System vor den Auswirkungen eines Wechsels der Implementierung geschützt werden.<br />
<br />
== Literatur ==<br />
* {{Literatur<br />
|Autor=Mark Grand<br />
|Titel=Patterns in Java<br />
|Auflage=2.<br />
|Verlag=John Wiley & Sons<br />
|Datum=1999<br />
|ISBN=0-471-25841-5<br />
|Sprache=en}}<br />
* {{Literatur<br />
|Autor=Craig Larman<br />
|Titel=Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development<br />
|Auflage=3.<br />
|Verlag=Markt und Technik<br />
|Datum=2005<br />
|ISBN=3-8272-6898-2<br />
|Sprache=en}}<br />
<br />
{{SORTIERUNG:Grasp}}<br />
[[Kategorie:Entwurfsmuster]]<br />
[[Kategorie:Objektorientierte Programmierung]]<br />
[[Kategorie:Softwarearchitektur]]<br />
[[Kategorie:Abkürzung]]</div>imported>Crazy1880