GRASP: Information Expert

Bei einer Diskussion mit Kollegen kam die Frage auf, welche Komponente für das Zählen der ungelesenen Nachrichten eines EMail-Postfachs zuständig ist. Speziell ging es dabei um eine App im Browser, die über einen Backend-Service auf ein EMail-Postfach zugreift. Folgendes Bild stellt eine vereinfachte Übersicht der vorhandenen Klassen dar:

Information Expert
Die Fragestellung („Wer ist für etwas zuständig?“) gibt bereits den Hinweis, dass hier GRASP (General Responsibility Assignment Software Patterns) weiterhelfen kann. Patterns bestehen aus fünf Abschnitten:
* Ein Name
* Eine (generalisierte) Problemstellung
* Eine Lösung / ein Ratschlag
* Eine Diskussion der Lösung
* Gegenanzeigen zur Verwedung des Patterns

Zurück zu dem Problem: „Wer zählt die ungelesenen Nachrichten eines EMail-Postfachs?“.Das Pattern „Information Expert“ gibt auf die Problemstellung „Welches Objekt soll für Aufgabe XYZ zuständig sein?“ den Ratschlag: „Das Objekt, welches alle nötigen Informationen zur Erfüllung der Aufgabe hat“. In unserem Beispiel besitzen die beiden verschiedenen EMail-Klassen (im Package „app“ und „backend“) zwar die Information, ob sie bereits gelesen wurden, allerdings besitzen sie keine Referenz auf alle Mails eines Postfachs. Also sollte laut „Information Expert“ das Zählen der ungelesenen Nachrichten nicht von den beiden EMail-Klassen (bzw. deren Instanzen) vorgenommen werden.

Die Klasse „EMailService“ liefert zu einer bestimmten PostfachID die ersten 50 EMails und hat keine permanente Referenz auf Postfächer. Interessanterweise wollten die meisten Kollegen die Zählfunktionalität hier einbauen. Wenn man sich aber den Zählalgorithmus an diese Stelle denkt (hole das Postfach XYZ, iteriere durch alle Emails und zähle die mit read = false), so sieht man, dass der Service mit den EMail-Objeten sprechen müsste. Das ist gegen das „Don’t talk to strangers“-Prinzip und hat Nachteile, wenn die EMail-Klasse verändert wird (da dann sowohl der EMailService, als auch die Inbox angepasst werden müssen).

Übrig bleiben die Klassen „EMailApp“ und „Inbox“. Jetzt sind genauere Anforderungen notwendig, um mit dem Information Expert Pattern hier eine Enscheidung treffen zu können. Sollen alle ungelesenen Nachrichten des gesamten Postfachs gezählt werden? Dann besitzt die „Inbox“ alle Informationen. Oder sollen nur die ungelesenen Nachrichten des angezeigten EMail-Postfachs (also der ersten 50 Nachrichten) gezählt werden? Dann besitzt die „EMailApp“ alle Informationen.

Das Information Expert Pattern gibt stets nur Ratschläge, die man nie isoliert betrachten sollte, sondern immer auch die anderen Pattern von GRASP konsultieren sollte. Geht man von dem Domainmodel aus, so stellt sich irgendwann die Frage: „Wer ist dafür zuständig, das Postfach darzustellen?“. Laut Information Expert zeichnet sich das Postfach selbst auf dem Bildschirm, schreibt und liest sich aus der Datenbank und hat auch sonst alle Aufgaben, für die es alle Informationen besitzt. Genau dafür gibt es aber andere GRASPs, die dem Ratschlag des Information Expert Patterns widersprechen (z.B. in diese Fall das „Pure Fabrication“ Pattern). Es darf also nie ein Pattern für sich alleine betrachtet werden.

Sehr gute Informationen zu GRASP gibt es in dem Buch „Applying UML and Patterns“ von „Craig Larman“, welches ich auch auf der Website Modellierung.net verlinkt habe.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.