Softwaredesignmuster

In der Softwaretechnik ist ein Designmuster eine allgemeine Mehrweglösung eines allgemein vorkommenden Problems innerhalb eines gegebenen Zusammenhangs im Softwaredesign. Ein Designmuster ist nicht ein beendetes Design, das direkt in den Code umgestaltet werden kann. Es ist eine Beschreibung oder Schablone dafür, wie man ein Problem behebt, das in vielen verschiedenen Situationen verwendet werden kann. So werden Muster beste Methoden formalisiert, die Sie selbst in Ihrer Anwendung durchführen müssen. Objektorientierte Designmuster zeigen normalerweise Beziehungen und Wechselwirkungen zwischen Klassen oder Gegenständen, ohne die Endanwendungsklassen oder Gegenstände anzugeben, die beteiligt werden. Viele Muster beziehen Gegenstand-Orientierung oder mehr allgemein veränderlichen Staat ein, und können so auf funktionellen Programmiersprachen so nicht anwendbar sein, auf denen Daten unveränderlich oder behandelt ist wie solcher.

Designmuster wohnen im Gebiet von Modulen und Verbindungen. An einem höheren Niveau gibt es architektonische Muster, die im Spielraum größer sind, gewöhnlich ein gesamtes von einem kompletten System gefolgtes Muster beschreibend.

Es gibt viele Typen von Designmustern wie

  • Algorithmus-Strategie-Muster, Sorgen richtend, haben sich auf Strategien auf höchster Ebene bezogen, die beschreiben, wie man Anwendungseigenschaft auf einer Rechenplattform ausnutzt.
  • Rechenbetonte Designmuster, Sorgen richtend, haben sich auf die Schlüsselberechnungsidentifizierung bezogen.
  • Ausführungsmuster, die Sorgen richten, die mit dem Unterstützen der Anwendungsausführung, einschließlich Strategien in der Durchführung von Strömen von Aufgaben und Bausteinen verbunden sind, um Aufgabe-Synchronisation zu unterstützen.
  • Durchführungsstrategie-Muster, Sorgen richtend, haben sich auf das Einführen des Quellcodes bezogen, um zu unterstützen
  • # Programm-Organisation und
  • # die allgemeinen Datenstrukturen, die spezifisch sind, um Programmierung anzupassen.
  • Strukturdesignmuster, Sorgen richtend, haben sich auf Strukturen auf höchster Ebene von Anwendungen bezogen, die entwickeln werden.

Geschichte

Muster sind als eine architektonische Gestaltung von Christopher Alexander (1977/79) entstanden. 1987 haben Kent Beck und Ward Cunningham begonnen, mit der Idee zu experimentieren, Muster auf die Programmierung anzuwenden, und haben ihre Ergebnisse auf der OOPSLA Konferenz in diesem Jahr präsentiert. In den folgenden Jahren, Beck, sind Cunningham und andere auf dieser Arbeit gefolgt.

Designmuster haben Beliebtheit in der Informatik nach den Buchdesignmustern gewonnen: Elemente der Objektorientierten Mehrwegsoftware wurden 1994 von der so genannten "Bande Vier" veröffentlicht (Gamma u. a.). Dass dasselbe Jahr die ersten Muster-Sprachen, Konferenz Zu programmieren, gehalten wurden, und im nächsten Jahr wurde das Portland Muster-Behältnis für die Dokumentation von Designmustern aufgestellt. Das Spielraum des Begriffes bleibt eine Sache des Streits. Bemerkenswerte Bücher im Designmuster-Genre schließen ein:

Obwohl Designmuster praktisch seit langem angewandt worden sind, hat die Formalisierung des Konzepts von Designmustern seit mehreren Jahren ermattet.

2009 haben mehr als 30 Mitwirkende mit Thomas Erl an seinem Buch, SOA Designmustern zusammengearbeitet. Die Absicht dieses Buches war, einen De-Facto-Katalog von Designmustern für SOA und Dienstorientierung zu gründen. (Mehr als 200 + ES Fachleuten haben weltweit an der Prüfung des Buches und Muster von Erl teilgenommen.) Diese Muster werden auch veröffentlicht und auf der Gemeinschaftsforschungsseite soapatterns.org besprochen

Praxis

Designmuster können den Entwicklungsprozess durch die Versorgung von geprüften, bewiesenen Entwicklungsparadigmen beschleunigen. Wirksames Softwaredesign verlangt das Betrachten von Problemen, die sichtbar bis später in der Durchführung nicht werden können. Das Wiederverwenden von Designmustern hilft, feine Probleme zu verhindern, die Hauptprobleme verursachen können, und es auch Codelesbarkeit für Codierer und Architekten verbessert, die mit den Mustern vertraut sind.

Um Flexibilität zu erreichen, führen Designmuster gewöhnlich zusätzliche Niveaus des Umwegs ein, der in einigen Fällen die resultierenden Designs komplizieren und Anwendungsleistung verletzen kann.

Definitionsgemäß muss ein Muster von neuem in jede Anwendung programmiert werden, die es verwendet. Da einige Autoren das als ein Schritt rückwärts vom Softwarewiedergebrauch gemäß Bestandteilen sehen, haben Forscher gearbeitet, um Muster in Bestandteile zu verwandeln. Meyer und Arnout sind im Stande gewesen, vollen oder teilweisen componentization von zwei Dritteln der Muster zur Verfügung zu stellen, die sie versucht haben.

Häufig verstehen Leute nur, wie man bestimmte Softwaredesigntechniken auf bestimmte Probleme anwendet. Diese Techniken sind schwierig, für eine breitere Reihe von Problemen zu gelten. Designmuster stellen allgemeine Lösungen zur Verfügung, die in einem Format dokumentiert sind, das an ein besonderes Problem gebundene Details nicht verlangt.

Struktur

Designmuster werden aus mehreren Abteilungen zusammengesetzt (sieh Dokumentation unten). Vom besonderen Interesse sind die Struktur, Teilnehmer und Kollaborationsabteilungen. Diese Abteilungen beschreiben ein Designmotiv: Eine archetypische Mikroarchitektur, die Entwickler kopieren und an ihre besonderen Designs anpassen, um das wiederkehrende durch das Designmuster beschriebene Problem zu beheben. Eine Mikroarchitektur ist eine Reihe von Programm-Bestandteilen (z.B, Klassen, Methoden...) und ihre Beziehungen. Entwickler verwenden das Designmuster, indem sie in ihren Designs diese archetypische Mikroarchitektur einführen, was bedeutet, dass Mikroarchitekturen in ihren Designs Struktur und dem gewählten Designmotiv ähnliche Organisation haben werden.

Zusätzlich dazu erlauben Muster Entwicklern, das Verwenden wohl bekannt, gut verstandene Namen für Softwarewechselwirkungen mitzuteilen. Allgemeine Designmuster können mit der Zeit verbessert werden, sie robuster machend, als ad hoc Designs.

Bereichsspezifische Muster

Anstrengungen sind auch gemacht worden, Designmuster in besonderen Gebieten, einschließlich des Gebrauches von vorhandenen Designmustern sowie Gebiet spezifische Designmuster zu kodifizieren. Beispiele schließen Benutzerschnittstelle-Designmuster, Informationsvergegenwärtigung ein, sichern Design, "sichern Sie Brauchbarkeit", Webdesign und Geschäftsmusterdesign.

Die jährlichen Muster-Sprachen, Konferenzverhandlungen Zu programmieren, schließen viele Beispiele des Gebiets spezifische Muster ein.

Klassifikation und Liste

Designmuster wurden in die Kategorien ursprünglich gruppiert: Creational-Muster, Strukturmuster, und Verhaltensmuster und das beschriebene Verwenden der Konzepte der Delegation, Ansammlung und Beratung. Für den weiteren Hintergrund auf dem objektorientierten Design, sieh Kopplung und Kohäsion, Erbe, Schnittstelle und polymorphism. Eine andere Klassifikation hat auch den Begriff des Musters der architektonischen Planung eingeführt, das am Architektur-Niveau der Software wie das MusterAnsicht-Kontrolleurmuster angewandt werden kann.

Dokumentation

Die Dokumentation für ein Designmuster beschreibt den Zusammenhang, in dem das Muster, die Kräfte innerhalb des Zusammenhangs verwendet wird, den sich das Muster bemüht, und die angedeutete Lösung aufzulösen. Es gibt keine Single, Standardformat, um Designmuster zu dokumentieren. Eher, eine Vielfalt von verschiedenen Formaten sind von verschiedenen Muster-Autoren verwendet worden. Jedoch, gemäß Martin Fowler, sind bestimmte Muster-Formen wohl bekannter geworden als andere, und werden folglich allgemeine Startpunkte für neue Muster schreibende Anstrengungen. Ein Beispiel eines allgemein verwendeten Dokumentationsformats ist dasjenige, das von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides (insgesamt verwendet ist, bekannt als die "Bande Vier", oder GoF für den kurzen) in ihren Buchdesignmustern. Es enthält die folgenden Abteilungen:

  • Muster-Name und Klassifikation: Ein beschreibender und einzigartiger Name, der im Identifizieren und Verweisen zum Muster hilft.
  • Absicht: Eine Beschreibung der Absicht hinter dem Muster und dem Grund dafür, es zu verwenden.
  • Auch bekannt als: Andere Namen für das Muster.
  • Motivation (Kräfte): Ein Drehbuch, das aus einem Problem und einem Zusammenhang besteht, in dem dieses Muster verwendet werden kann.
  • Anwendbarkeit: Situationen, in denen dieses Muster verwendbar ist; der Zusammenhang für das Muster.
  • Struktur: Eine grafische Darstellung des Musters. Klassendiagramme und Wechselwirkungsdiagramme können für diesen Zweck verwendet werden.
  • Teilnehmer: Eine Auflistung der Klassen und Gegenstände, die im Muster und ihren Rollen im Design verwendet sind.
  • Kollaboration: Eine Beschreibung dessen, wie Klassen und im Muster verwendete Gegenstände mit einander aufeinander wirken.
  • Folgen: Eine Beschreibung der Ergebnisse, der Nebenwirkungen und des Handels offs verursacht durch das Verwenden des Musters.
  • Durchführung: Eine Beschreibung einer Durchführung des Musters; der Lösungsteil des Musters.
  • Beispielcode: Eine Illustration dessen, wie das Muster auf einer Programmiersprache verwendet werden kann.
  • Bekannter Gebrauch: Beispiele des echten Gebrauchs des Musters.
  • Zusammenhängende Muster: Andere Muster, die etwas Beziehung mit dem Muster haben; Diskussion der Unterschiede zwischen dem Muster und den ähnlichen Mustern.

Kritik

Das Konzept von Designmustern ist auf mehrere Weisen kritisiert worden.

Die Designmuster können gerade ein Zeichen von einigen fehlenden Eigenschaften einer gegebenen Programmiersprache (Java oder C ++ zum Beispiel) sein. Peter Norvig demonstriert, dass 16 aus den 23 Mustern im Designmuster-Buch (der in erster Linie C ++ konzentriert wird) vereinfacht oder (über die direkte Sprachunterstützung) im Lispeln oder Dylan beseitigt werden. Siehe auch den Aufsatz von Paul Graham Rache der Trottel.

Die Idee kann so nicht neu sein wie angedeutet von den Autoren: Zum Beispiel ist das MusterAnsicht-Kontrolleurparadigma ein Beispiel eines "Musters", das das Konzept von "Designmustern" um mehrere Jahre zurückdatiert.

Außerdem kann der unpassende Gebrauch von Mustern Kompliziertheit unnötigerweise vergrößern.

Siehe auch

  • Abstraktionsgrundsatz
  • Algorithmisches Skelett
  • Antimuster
  • Architektonisches Muster
  • Verteilte Designmuster
  • Doppelt-Zufallsfunktion
  • Unternehmensarchitektur-Fachwerk
  • GRIFF (objektorientiertes Design)
  • Wechselwirkungsdesignmuster
  • Liste von Softwareentwicklungsphilosophien
  • Liste von Softwaretechnikthemen
  • Muster-Sprache
  • Muster-Theorie
  • Pädagogische Muster
  • Portland Muster-Behältnis
  • Wiederfactoring
  • Softwareentwicklungsmethodik

Weiterführende Literatur

Links

am Portland Muster-Behältnis am Portland Muster-Behältnis am Portland Muster-Behältnis

Taylor Caldwell / Reinheitstest
Impressum & Datenschutz