Speziell für den Start eines neuen Sets für den Kurs "Architektur- und Designmuster" setze ich meine Publikationsreihe über GRASP-Muster fort.
Einführung
GRASP-Muster werden in Craig Larmans Buch "Anwenden von UML und Mustern, 3. Auflage" beschrieben und sind Verallgemeinerungen von GoF-Mustern sowie eine direkte Folge der Prinzipien von OOP. Sie ergänzen den fehlenden Schritt in der logischen Leiter, mit dem Sie GoF-Muster aus OOP-Prinzipien ableiten können. GRASP-Muster sind keine Entwurfsmuster (wie die von GoF), sondern die Grundprinzipien für die Aufteilung der Verantwortung zwischen Klassen. Wie die Praxis zeigt, sind sie nicht sehr beliebt, aber die Analyse der entworfenen Klassen unter Verwendung des vollständigen Satzes von GRASP-Mustern ist eine Voraussetzung für das Schreiben von gutem Code.
Die vollständige Liste der GRASP-Vorlagen besteht aus 9 Elementen:
- Informationsexperte
- Schöpfer
- Regler
- Niedrige Kupplung
- Hoher Zusammenhalt
- Polymorphismus
Das letzte Mal haben wir das Controller-Muster besprochen . Heute schlage ich vor, die verbleibenden Muster aus der Liste zu berücksichtigen.
Polymorphismus
Je nach Typ sollten unterschiedliche Verhaltensweisen behandelt werden, um den Austausch von Systemteilen zu ermöglichen.
Es wird vorgeschlagen, die Verantwortlichkeiten mithilfe polymorpher Operationen auf Klassen zu verteilen, wobei jedes externe System über eine eigene Schnittstelle verfügt. Als Beispiel können wir standardisierte Bibliotheken oder Anwendungskonfigurationen zitieren, indem wir bestimmte Plugins für verschiedene Kunden entsprechend ihren Anforderungen verbinden.
Das Vorhandensein einer Schalterkonstruktion im Code verstößt gegen dieses Prinzip, wechselt und unterliegt einem Refactoring.
Übermäßiger Gebrauch von Polymorphismus führt zu einer Überkomplexität des Codes und wird im Allgemeinen nicht empfohlen.
Reine Herstellung
Eine geringe Kopplung und ein hoher Zusammenhalt müssen gewährleistet sein. Zu diesem Zweck kann es notwendig sein, eine künstliche Essenz zu synthetisieren. Das Pure Fabrication-Muster legt nahe, dass Sie nicht zögern sollten, dies zu tun. Betrachten Sie als Beispiel die Fassade zur Datenbank. Dies ist ein rein künstliches Objekt, das im Themenbereich keine Analoga aufweist. Im Allgemeinen gehört jede Fassade zu Pure Fabrication (es sei denn, es handelt sich natürlich um eine Architekturfassade in der entsprechenden Anwendung).
Indirektion
Es ist notwendig, die Verantwortlichkeiten auf die Objekte zu verteilen, um eine direkte Bindung zu vermeiden. Zu diesem Zweck können Sie einem Zwischenobjekt Verantwortlichkeiten für die Kommunikation zwischen Komponenten oder Diensten zuweisen.
Das ins Russische übersetzte Muster impliziert Folgendes: Jedes Objekt im Code muss über seine Schnittstelle aufgerufen werden (dasselbe Zwischenobjekt).
Indirektion ist das in diesem Artikel am häufigsten aufgeführte Schlüsselmuster. Erstens ist es in Bezug auf die Sicherheit sehr einfach. Zweitens bietet es dem Code viel Flexibilität, ohne aufgrund des ersten Punktes vorzeitige Optimierungen vorzunehmen. Wenn sich alle Klassen über Schnittstellen gegenseitig aufrufen, kann dies dazu führen, dass jedes Teil aus dem System "gerissen" und an anderer Stelle wiederverwendet werden kann. Darüber hinaus können Sie mit Indirection fast jede Vorlage einer Vierergruppe hinzufügen, ohne zu viele Belastungs- oder Refaktorklassen.
Geschützte Variationen
Das System muss so gestaltet werden, dass Änderungen an einigen Elementen keine Auswirkungen auf andere haben. Als Lösung wird vorgeschlagen, Punkte möglicher Änderungen oder Instabilitäten zu identifizieren und Verantwortlichkeiten so zuzuweisen, dass ein stabiler Betrieb des Systems gewährleistet ist.
Tatsächlich ist dies kein Muster, sondern ein Ziel, das durch Befolgen der übrigen Muster erreicht wird.
Ausgabe
GRASP-Vorlagen bestehen aus 8 Mustern:
- Informationsexperte - Wir verarbeiten Informationen dort, wo sie enthalten sind.
- Schöpfer - Wir erstellen Objekte dort, wo sie benötigt werden.
- Controller - Wir verschieben die Multithreading-Logik in eine separate Klasse oder Komponente.
- Geringe Kopplung 5) Hohe Kohäsion - Wir entwerfen Klassen mit homogener Geschäftslogik und einer minimalen Anzahl von Verbindungen untereinander.
- Polymorphismus - Wir arrangieren bei Bedarf verschiedene Optionen für das Systemverhalten in Form von polymorphen Aufrufen.
- Pure Fabrication — , , Low Coupling High Cohesion.
- Indirection — .
- Protected Variations — , .
: