Patterns

Patterns und Pattern-Beschreibungen

Zu Patterns gibts mehrere Definitionen (eben die aus den bekannten Pattern-Büchern). In meinen Augen vermischen diese Definitionen jedoch oft die Musterbeschreibung mit dem eigentlichen Muster. Das ist jetzt nicht essenziell wichtig und man kann sich über Definitionen sicher trefflich streiten. Welche Definition man nun bevorzugt, ist meiner Meinung nach zweitrangig, aber dennoch muss man ja irgendwie auf Begriffe einigen. Und da das hier mein Blog ist, folgen hier einfach meine eigenen Definitionen:

Definition: Pattern

Ein „Muster“ oder „Pattern“ ist eine häufig anzutreffende, für gut befundene Lösung zu einem wiederkehrenden Problem.

An dieser Definition erkennt man, dass Patterns nicht erfunden, sondern entdeckt werden. Man bemerkt, dass man ein bestimmtes Problem mehrmals auf gleiche oder ähnliche Weise gelöst hat und stellt fest, dass sich diese Lösung bewährt. Man erkennt sozusagen ein Muster im Code (oder in den Diagrammen oder was auch immer). Daher auch der Name „Muster“: Eine gute Lösung wiederholt sich.

Hat man ein Muster gefunden, kann man es isolieren, beschreiben und dokumentieren. Erst dadurch wird es wirklich wiederverwendbar. Auch bei Code ist das isolieren, parametrisieren und dokumentieren notwendig, um ein Stück Code wiederverwendbar zu machen.

Definition: Muster-Beschreibung

Eine „Muster-Beschreibung“ (pattern description) ist ein Dokument das zu einem Pattern die folgenden Informationen angibt:

  • den Kontext, indem es angewendet werden kann
  • das Problem, also die miteinander in Konflikt stehenden Kräfte
  • sowie eine Möglichkeit, diese Kräfte auszubalancieren, also die Lösung bzw. das Pattern selbst.

Typischerweise enthalten Musterbeschreibungen noch weitere Informationen:

  • Beispiele für die Anwendung
  • Beispielcode
  • Beschreibungen von Varianten
  • Beziehungen zu anderen Patterns

Hier sieht man die Verbindung zu den Prinzipien und Daumenregeln, die hier „Kräfte“ genannt werden. Bei der Softwareentwicklung geht es generell darum, Prinzipien oder „Kräfte“ auszubalancieren. Und Patterns sind quasi fertig ausbalancierte Standardlösungen.

Der Vollständigkeit halber hier noch ein paar „offizielle“ Definitionen:

  • Christopher Alexander: Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
  • Auch Alexander: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
  • GoF: A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.
  • POSA: A pattern […] describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.

Kapitel: | Zurück | 1 | 2 | 3 | 4 | 5 | 6 | Weiter |

3 Kommentare


  1. > _In_ meinen Augen vermischen diese Definitionen jedoch oft

    Typo.


  2. > Außerdem muss bei Änderung der GUI die _ChatClient_-Klasse angepasst werden

    Typo.

Schreibe einen Kommentar

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