Welche Design Patterns sollte man kennen?
-
Das Singleton Pattern ist eine Lösung für Probleme bei denen es nur ein Objekt geben darf. Wenn du z.B. die Verteilung von begrenzen Ressourcen regeln willst, bietet sich ein Singleton an, damit nur ein Objekt die Ressourcen verteilt und nicht zuviele verteilt werden. Das es in dem Buch und in vielen anderen objektorientiert beschrieben ist, liegt wohl daran, dass das gerade modern ist. Ein Singleton ist nicht die oo Schreibweise für globale Variablen. Sinn des Singleton Patterns ist es auch nicht eine Vorschrift zu liefern, wie man Klassen schreiben muss, damit man nur eine Instanz erstellen kann. Wahrscheinlich kann man in einigen Sprachen trotzdem eine zweite Instanz erstellen, wenn man irgendwelche Mem-Copy und Casting Hacks verwendet. Man macht es aber nicht, weil es nicht dem Softwaredesign entspricht und dann die Software das Problem nicht mehr löst. Du kannst die Idee des Singletons auch implementieren, wenn du keine Klassen hast. Dann greifst du z.B. auf eine bestimmte Struktur nur über bestimmte Methoden zu und musst bei der Implementierung drauf achten, dass du es nicht anderst machst, obwohl es möglich wäre. Ist dann zwar nicht mehr so schön wie in Klassen verpackt, aber die gleiche Idee.
Ein Funktionsaufruf ist auch eine Lösung für bestimmte Probleme, z.B. gleichen Code an verschiedenen Stellen auszuführen, ohne ihn zu kopieren.
Das sind aber Probleme auf unterschiedlichen Ebenen. Bei einem Design Pattern steckt eine Idee auf Softwaredesignebene dahinter und nicht einfach nur eine Idee wie man etwas implementiert. Das man beschreibt, wie man sowas möglichst effizient und sauber implementiert, gehört halt dazu, wenn man Ideen liefert wie man sauber und verständlich designt. Eine gute Idee bringt halt nicht viel, wenn sie schlecht und kompliziert umgesetzt wird.
-
antwort schrieb:
Sinn des Singleton Patterns ist es auch nicht eine Vorschrift zu liefern, wie man Klassen schreiben muss, damit man nur eine Instanz erstellen kann.
Was wenn die Sprache das aber direkt unterstuetzt?
Genau darum geht es Helium ja, soweit ich ihn verstanden habe.
Meiner Meinung nach entsteht ein Design Pattern immer dann, wenn man ein Konzept in eine Sprache einbauen will, die diese nicht native beherrscht.
-
Es ist nicht der Sinn des Singleton Pattern eine solche Vorschrift zu liefern, also ist es egal ob eine Sprache es direkt unterstützt.
-
antwort schrieb:
Es ist nicht der Sinn des Singleton Pattern eine solche Vorschrift zu liefern, also ist es egal ob eine Sprache es direkt unterstützt.
Genau darum geht es aber - ist jedes Konzept ein Design Pattern?
Ist a=b; das Assignment Pattern?
-
Gucken wir uns doch einfach ein stückchen Code an:
foo ist eine Fuktion und ich übergebe ihr den Ausdruck 42:
-- Beispiel 1a foo 42
Wunderbar. Einfacher Funktionsaufruf. Nix besonderes. Nächstes Beispiel. bar ist eine Funktion und ich übergebe ihr den Ausdruck "42":
-- Beispiel 2a bar "42"
Hmm, ja nix neues. Weiteres Beispiel. baz ist eine Funktion und ich übergebe ihr den Ausdruck (42+):
-- Beispiel 3a baz (42+)
Hmm, ja und?. Irgendwie immer noch nichts neues. Es werden einfach Funktionen mit 'nem Argument aufgerufen.
Modifizieren wir die Beispiele ein kleines bischen. Statt das Argument direkt zu übergeben binde ich den Wert an eine Variable und übergebe die Variable:
-- Beispiel 1b tmp = 42 foo tmp
Toll. Code macht das selbe. Ist auch nix außergewöhnliches. Modifizieren wir das zweite Beispiel auf die selbe weise:
-- Beispiel 2b tmp = "42" bar tmp
Schön. Jetzt noch das letzte:
-- Beispiel 3b tmp = (42+) baz tmp
Ja, wunderbar. Langweilig. Ist doch immer das selbe. Ausdruck wird an Variable gebunden, Funktion wird mit Variable als Argument aufgerufen.
Nein Moment! Ist dir etwa nicht aufgefallen, dass Beispiel 3b etwas ganz anderes ist, als alle anderen? Beispiel 3b ist doch eine Anwendung des Command Patterns!
Ah ja ... WTF?
-
Beispiel 3b ist dann eine Anwendung des Command Patters, wenn sich dahinter dieses Befindet und damit ein Problem nach diesem Muster gelöst wird.
Nur weil man etwas so implementiert, dass es so aussieht wie ein Singleton, wird noch nicht die Idee dahinter verwendet, falls man es z.B. nur als Ersatz für eine einfache globale Variable nimmt.
-
Beschreibe mir das "Muster" mit deinen Worten und ich sage dir, ob es dieses "Muster" erfüllt.
Falls es in die Richtung geht, wie "the Command pattern is a design pattern in which objects are used to represent actions", dann erfüllt 3b definitiv dieses Muster. tmp ist genau dazu da die Aktion des Addierens von 42 zu einem belibigen Argument zu repräsentieren.
Fragt sich dann nur, warum es kein Pattern gibt, dessen Beschreibung in etwa lautet "the ... pattern is a design pattern in which objects are used to represent numbers" oder eins, dessen Beschreibung lautet "the ... pattern is a design pattern in which objects are used to represent text".
-
Mit dem Command Pattern kannst du die Ausführung der Aktion unabhängig vom Erstellen machen. Du fügst Aktion und Daten zu einer Einheit zusammen und kannst dann verschiedene Aktionen beliebig ordnen. Das mag vielleicht in einigen Sprachen einfach zu implementieren sein und dir trivial erscheinen, weil du die Idee kennst, aber es ist bei weitem nicht so trivial und allgemein wie "Objekt ist Nummer". Was sollen diese Objekt ist Nummer Patters für Designprobleme lösen? Das ist einfach so allgemein und doch irgendwie so eingeschränkt, dass ich da keine Idee sehe, die mir bei der Lösung einer Problemgruppe helfen würde.
-
antwort schrieb:
Mit dem Command Pattern kannst du die Ausführung der Aktion unabhängig vom Erstellen machen. Du fügst Aktion und Daten zu einer Einheit zusammen und kannst dann verschiedene Aktionen beliebig ordnen.
Das ist genau was
tmp = (42+) baz tmp
macht.
Beantworte mir deshalb folgende Frage:
a=b;
ist das das Assignment Pattern?
-
antwort schrieb:
Du fügst Aktion und Daten zu einer Einheit zusammen und kannst dann verschiedene Aktionen beliebig ordnen.
Du meinst eine Closure?
Das mag vielleicht in einigen Sprachen einfach zu implementieren sein und dir trivial erscheinen, weil du die Idee kennst, aber es ist bei weitem nicht so trivial und allgemein wie "Objekt ist Nummer".
Für mich ist die Aussage "Objekt ist Closure" tatsächlich nicht komplizierter als "Objekt ist Nummer".
Was sollen diese Objekt ist Nummer Patters für Designprobleme lösen?
Stell dir vor Zahlen wären nicht in die Spache eingebaut. Du würdest sie dir selbst bauen. Es könnte dann gängig sein, eine Enumeration mit genau zwei Zuständen zu bauen (quasi eigene Bits) und dann Arrays davon anzulegen mit einer bestimten Größe. So könnte man dann Zahlen darstellen. Ein Array von einer Enumeration die genau zwei zustände Annhemen kann wäre dann das "Objekt ist Nummer" Pattern.
Siehst du, sobald etwas nicht mehr trivial ist, aber immer wieder gebraucht wird wird es zum Design Pattern, auch das "Objekt ist Nummer" Pattern.
-
Helium schrieb:
Das mag vielleicht in einigen Sprachen einfach zu implementieren sein und dir trivial erscheinen, weil du die Idee kennst, aber es ist bei weitem nicht so trivial und allgemein wie "Objekt ist Nummer".
Für mich ist die Aussage "Objekt ist Closure" tatsächlich nicht komplizierter als "Objekt ist Nummer".
Die Idee ist aber komplizierter, auch wenn die Aussagen gleich klingen.
Mit Closures kannst du auch noch andere Sachen machen, als das Command Pattern umsetzen. Closures erklären dir nicht die Idee des Patterns. Nur weil du Closures kennst, musst du noch nicht auf die Idee kommen, sie so einzusetzen, dass du ein Problem mit diesem Pattern löst. Es ist zwar wahrscheinlich, dass du irgendwann auf die Idee kommst das Command Pattern zu implementieren, aber ich habs ja schon gesagt, man implementiert Patterns auch mal zufällig, auch wenn man sie nicht kennt.
Natürlich kannst du ein "Objekt ist Nummer" Patter definieren. So wie du es gemacht hast ist es zum einen unrealistisch, weil eine Sprache in der es keine Zahlen gibt auch keine Pointer hätte (Adressen sind auch Zahlen) und somit nichts im PC ansprechen könnte. Und ich seh auch nicht wirklich ein Muster für eine Problemgruppe, sondern einfach nur eine Lösung wie man Zahlen simulieren könnte.
Shade Of Mine schrieb:
a=b;
ist das das Assignment Pattern?
Und was soll die Idee hinter dem Assignment Pattern sein? Was für Designprobleme löst es? Ich seh da kein Muster das bestimmte Probleme löst. Es ist einfach so allgemein, dass es alles und nichts löst. Ein Pattern beschreibt ein Muster, mit dem man bestimmte Probleme softwaretechnisch lösen kann. Eine Zuweisung löst noch kein Problem.
-
man ist das hier wieder eine seltsame diskussion....
patterns sind viel mehr, als irgendwelche features, die in einer sprache fehlen...
würde echt gerne mal wissen, wie ihr das pipes and filters oder microkernel pattern als sprachfeature implementieren würdet. composite würde auch schon reichen...:D oder auch irgendwelche analysis patterns, wie z.b. accountabilitypatterns sind benennungen von lösungsansätzen für bestimmte, immer wieder auftretende einigermaßen komplexe probleme. es gibt beliebig viele möglichkeiten wie man solche patterns konkret umsetzt, es ist immer problem- und kontextabhängig. wer bspw. allgemeingültige patternbibliotheken schreibt, der hat nicht verstanden was ein pattern ist. es gibt sicherlich patterns, z.b. visitor, die in sprachen teilweise konkret unterstützt werden (multimethods). ein visitor kann aber auch viel mehr sein. ein SAX-handler ist z.b. doch auch nichts weiter als ein visitor, der den xml baum durchgeht. oder das command pattern: eine kleine erweiterung und du kannst mit dem command pattern active objects realisieren oder das "rückgängig machen" von aktionen. plötzlich hat das kaum was mit closures zu tun, oder? :-).
-
Ich möchte mich mach 5 Jahren "Drauflosprogrammieren" gerne mal mit diesen "Design Patterns" auseinandersetzen. Gibt es irgendwo eine Liste mit allen "Design Patterns" incl. Beispiele?
-
excited boy schrieb:
Ich möchte mich mach 5 Jahren "Drauflosprogrammieren" gerne mal mit diesen "Design Patterns" auseinandersetzen. Gibt es irgendwo eine Liste mit allen "Design Patterns" incl. Beispiele?
Auf Wikipedia gibts eine kleine Übersicht
-
-
antwort schrieb:
Mit Closures kannst du auch noch andere Sachen machen, als das Command Pattern umsetzen. Closures erklären dir nicht die Idee des Patterns.
Closures machen das Pattern unnoetig.
In einer Sprache die Closures kann wirst du nie in die Verlegenheit kommen dir ein Pattern wie Command auszudenken, weil es einfach total natuerlich ist.
Wikipedia sagtIn object-oriented programming, the Command pattern is a design pattern in which objects are used to represent actions. A command object encapsulates an action and its parameters.
Genau das ist ein Closure. Genau das macht ein Closure.
Shade Of Mine schrieb:
a=b;
ist das das Assignment Pattern?
Und was soll die Idee hinter dem Assignment Pattern sein? Was für Designprobleme löst es? Ich seh da kein Muster das bestimmte Probleme löst. Es ist einfach so allgemein, dass es alles und nichts löst. Ein Pattern beschreibt ein Muster, mit dem man bestimmte Probleme softwaretechnisch lösen kann. Eine Zuweisung löst noch kein Problem.
Und genau hier haengen wir. Es loest das Allgemeine Problem dass ich Daten kopieren will.
Zu allgemein? Aber was ist zu allgemein?
Command ist zB mit Closures einfach trivial. Du musst nichts kapseln, du machst lediglich closure-Zuweisungen, mehr nicht.Jedes Pattern kann man so reduzieren. Beispiel Visitor. Wenn die Sprache eine Klasse einfach fuer Erweiterungen oeffnet, ist das komplette Pattern unnoetig weil trivial durch eine Funktionsdefinition zu implementieren.
Wo trennt man hier. Ab wann ist etwas zu trivial? Genau da scheitern IMHO die meisten Leute an Pattern. Wenn die Sprache das Konzept unterstuetzt, wird das Pattern nie entstehen. Deshalb gibt es kein Assignment Pattern.
Aber dazu muss man mal mit solchen Sprachen gearbeitet haben um das zu verstehen. Pattern geben Konzepten die die Sprache nicht direkt Unterstuetzt einen Namen - mehr nicht. Man koennte das Command Pattern auch Closure-Pattern nennen - nur wuerde das nicht ganz stimmen weil Closures einfach unendlich maechtiger sind als das Command Pattern. Command ist etwas das man mit Closures ohne Probleme machen kann.
-
antwort schrieb:
Natürlich kannst du ein "Objekt ist Nummer" Patter definieren. So wie du es gemacht hast ist es zum einen unrealistisch
Aha. Eine Sprache in der es exakt 100%ig so gemacht wird, wie von mir beschreiben existiert aber. Sie ist ansonsten Java recht ähnlich. Du musst dir das entsprechende Paper aber selbst raussuchen, weil ich da gerade echt keinen Bock zu habe.
Und ich seh auch nicht wirklich ein Muster für eine Problemgruppe, sondern einfach nur eine Lösung wie man Zahlen simulieren könnte.
Genau so sehe ich im Command Pattern keine Lösung für ein Problem. Ich sehe einfach nur eine Lösung, wie man in einigen Situationen Closures simulieren könnte. Aber bevor du überhaupt jemals mit Closures gearbeitet hast werde ich nicht mehr weiter darüber sprechen.
oder das "rückgängig machen" von aktionen. plötzlich hat das kaum was mit closures zu tun, oder? :-).
Du meinst ich pack in 'ne Liste Closures rein, die die gemachten Aktionen Rückgängig machen? Und wenn ich auch noch ein Wiederherstellen haben will, dann pack ich in die Liste paarweise auch noch die Closures, die die eigentliche Aktion durchgeführt haben, so dass ich beliebig vor und zurück kann?
@patternfreak: Moment, moment, wir reden hier von klassischen Design Pattern, nicht von Architectural Pattern. IMO sind die beiden zu trennen. Du hätest vielleicht Model-View-Controller nennen sollen, als Beispiel, was wohl jeder hier kennt, also die grundlegende Überlegung die Daten von deren Darstellung zu trennen. Oder damit die Leute, die nichts mit Architectural Pattern anfangen können, wissen, wie allgemein Architectual Pattern sind, vielleicht einfach Peer-to-Peer.
Wenn ich in 'ner Shell ein paar Programme zusammenhänge, wie grep ... | sort | uniq dann habe ich schon das Architectural Pattern "pipes and filters" erfüllt. Aber ich erfülle es auch, wenn ich mit dem o Operator ein bischen Funktionskomposition betreibe. Das ist IMO etwas Grundlegend anderes, als z.B. das Command Pattern.
Und ich stimme dir 100%ig zu, dass Architectural Pattern nichts sind, was auf fehlende Sprachfeatures hindeutet.
-
Shade Of Mine schrieb:
a=b;
ist das das Assignment Pattern?
Und was soll die Idee hinter dem Assignment Pattern sein? Was für Designprobleme löst es? Ich seh da kein Muster das bestimmte Probleme löst. Es ist einfach so allgemein, dass es alles und nichts löst. Ein Pattern beschreibt ein Muster, mit dem man bestimmte Probleme softwaretechnisch lösen kann. Eine Zuweisung löst noch kein Problem.
interessant wirds bei
a=a; //Selbstzuweisung
weiß allerdings nicht, ob es dafür ein entsprechendes Pattern gibt, bzw. ob sowas überhaupt über ein Pattern gelöst werden muss
-
Das ist doch das SelfAssignmentPattern
-
Shade Of Mine schrieb:
Man koennte das Command Pattern auch Closure-Pattern nennen - nur wuerde das nicht ganz stimmen weil Closures einfach unendlich maechtiger sind als das Command Pattern.
Merkst du was? Closures sind nicht das Command Pattern. Das Command Pattern ist kein Ersatz für Closures.
Helium schrieb:
Und ich seh auch nicht wirklich ein Muster für eine Problemgruppe, sondern einfach nur eine Lösung wie man Zahlen simulieren könnte.
Genau so sehe ich im Command Pattern keine Lösung für ein Problem. Ich sehe einfach nur eine Lösung, wie man in einigen Situationen Closures simulieren könnte.
...oder das "rückgängig machen" von aktionen. plötzlich hat das kaum was mit closures zu tun, oder? :-).
Du meinst ich pack in 'ne Liste Closures rein, die die gemachten Aktionen Rückgängig machen? Und wenn ich auch noch ein Wiederherstellen haben will, dann pack ich in die Liste paarweise auch noch die Closures, die die eigentliche Aktion durchgeführt haben, so dass ich beliebig vor und zurück kann?
Bist du dir wirklich sicher, dass du das Command Patter richtig verstanden hast?
Das Command Pattern ist mehr als der erste Satz aus dem Wikipedia Artikel.