Seit ich vor mindestens 10 Jahren zum ersten Mal von den Designmustern der Gang of Four (GoF) erfahren habe, habe ich den Eindruck, dass diese 23 Muster nur eine kleine Auswahl von etwas viel Größerem sein sollten, das ich gerne als Pattern Space bezeichne . Dieser hypothetische Musterraum besteht aus allen empfehlenswerten Lösungen (bekannt oder unbekannt) für häufig auftretende objektorientierte Softwareentwurfsprobleme.
Daher habe ich erwartet, dass die Anzahl der bekannten und dokumentierten Entwurfsmuster erheblich zunehmen wird.
Es ist nicht geschehen. Mehr als 20 Jahre nach Erscheinen des GoF-Buches sind im Wikipedia-Artikel nur 12 zusätzliche Muster aufgeführt, von denen die meisten viel weniger beliebt sind als die ursprünglichen. (Ich habe die Parallelitätsmuster hier nicht angegeben, da sie ein bestimmtes Thema abdecken.)
Was sind die Gründe?
Ist der GoF-Mustersatz tatsächlich umfassender als ich denke?
Hat das Interesse an der Suche nach neuen Mustern nachgelassen, vielleicht weil sich herausgestellt hat, dass sie im Software-Design nicht allzu nützlich sind?
Etwas anderes?
quelle
Antworten:
Als das Buch herauskam, dachten viele Leute so und es gab viele Bemühungen, "Musterbibliotheken" oder sogar "Mustergemeinschaften" zu schaffen. Sie können noch einige von ihnen finden:
Aber dann...
Das sehr. Der Punkt bei Entwurfsmustern ist die Verbesserung der Kommunikation zwischen Entwicklern. Wenn Sie jedoch versuchen, weitere Muster hinzuzufügen, gelangen Sie schnell an den Punkt, an dem sich die Benutzer nicht mehr an sie erinnern oder sie nicht mehr erinnern können oder nicht mehr darüber einig sind, wie sie genau aussehen sollen und wie die Kommunikation aussieht in der Tat nicht verbessert. Das passiert schon viel mit den GoF-Mustern.
Persönlich würde ich noch weiter gehen: Software-Design, insbesondere gutes Software-Design, ist viel zu vielfältig, um in Mustern sinnvoll erfasst zu werden, insbesondere in der geringen Anzahl von Mustern, an die sich Menschen tatsächlich erinnern können - und sie sind viel zu abstrakt für Menschen Erinnere dich wirklich an mehr als eine Handvoll. Sie helfen also nicht viel.
Und viel zu viele Menschen verlieben sich in das Konzept und versuchen, überall Muster anzuwenden - normalerweise findet man im resultierenden Code nicht das tatsächliche Design zwischen allen (völlig bedeutungslosen) Singletons und Abstract Factories.
quelle
ControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
Dies ist die schreckliche Annahme, die von Neulingen-Programmierern überall verbreitet wird, Programmierern, die glauben, ein Programm nur durch Zusammenfügen von Softwaremustern schreiben zu können. So funktioniert das nicht. Wenn es einen solchen "Musterraum" gibt, können Sie davon ausgehen, dass seine Größe praktisch unendlich ist.
Entwurfsmuster (im Sinne von GoF) haben nur einen Zweck: Mängel in der von Ihnen verwendeten Programmiersprache auszugleichen.
Entwurfsmuster sind weder universell noch umfassend. Wenn Sie zu einer anderen, ausdrucksstärkeren Programmiersprache wechseln, werden die meisten Muster im GoF-Buch unnötig und unerwünscht.
quelle
ObservableSomething<T>
, was es einfach macht, ihren Zweck zu verstehen, da der allgemein bekannte Mustername verwendet wird. Ein Muster ist eine Idee, keine genaue Umsetzung.Ich denke, hier spielen drei Faktoren eine Rolle.
Mangel an kritischer Masse
Erstens ist ein Muster im Grunde nichts anderes, als einem Code einen Namen zu geben, der einen bestimmten Teil der Funktionalität implementiert. Der Name bietet nur dann einen echten Nutzen, wenn Sie sich darauf verlassen können, dass jeder weiß, was der Name bedeutet. Wenn er nur den Namen verwendet, versteht er sofort eine Menge über den Code.
Patterns haben jedoch nie die kritische Masse erreicht, die sie dazu benötigten. Eher das Gegenteil, AAMOF. Ich bin mir ziemlich sicher, dass ich in den 20 (oder so) Jahren seit Erscheinen des GoF-Buches nicht ein Dutzend Konversationen gesehen habe, in denen alle Beteiligten wirklich genug Entwurfsmuster kannten, um die Kommunikation zu verbessern.
Um es etwas kurioser auszudrücken: Designmuster scheiterten speziell daran, dass sie scheiterten.
Zu viele Muster
Ich denke, der zweite Hauptfaktor ist, dass sie anfangs, wenn überhaupt, zu viele Muster benannt haben. In einer Reihe von Fällen sind die Unterschiede zwischen den Mustern hinreichend subtil, so dass es nahezu unmöglich ist, mit wirklicher Gewissheit zu sagen, ob eine bestimmte Klasse zu dem einen oder anderen Muster passt (oder vielleicht zu beiden - oder vielleicht auch zu keinem).
Die Absicht war, dass Sie auf einer höheren Ebene über Code sprechen können. Sie können einen relativ großen Codeabschnitt als Implementierung eines bestimmten Musters bezeichnen. Wenn Sie einfach diesen vordefinierten Namen verwenden, weiß normalerweise jeder, der zuhört, so viel, wie er sich um diesen Code kümmert, sodass Sie zum nächsten Schritt übergehen können.
Die Realität sieht eher anders aus. Nehmen wir an, Sie sind in einer Besprechung und sagen ihnen, dass es sich bei dieser bestimmten Klasse um eine Fassade handelt. Die Hälfte der Teilnehmer des Treffens wusste entweder nie oder hat längst vergessen, was das genau bedeutet. Einer von ihnen bittet Sie, ihn an die genauen Unterschiede zwischen einer Fassade und beispielsweise einem Stellvertreter zu erinnern. Oh, und die paar Leute, die wirklich Muster kennen, verbringen den Rest des Meetings damit zu diskutieren, ob dies wirklich als Fassade oder "nur" als Adapter angesehen werden sollte (wobei dieser eine Mann immer noch darauf besteht, dass es ihm wie ein Stellvertreter vorkommt).
In Anbetracht dessen, dass Sie wirklich nur sagen wollten: "Dieser Code ist nicht sehr interessant. Machen wir weiter." Der Versuch, den Namen eines Musters zu verwenden, hat nur Ablenkung und keinen Wert.
Mangel an Interesse
Die meisten Entwurfsmuster beschäftigen sich nicht wirklich mit den interessanten Teilen des Codes. Sie beschäftigen sich mit Dingen wie: "Wie erstelle ich diese Objekte?" Und "Wie bringe ich dieses Objekt dazu, mit diesem zu sprechen?" Das Auswendiglernen von Musternamen für diese (sowie die oben genannten Argumente über Details und dergleichen) bedeutet einfach, viel Energie in Dinge zu stecken, die den meisten Programmierern einfach nicht so wichtig sind.
Um es etwas anders: Muster beschäftigen sich mit den Dingen , die die gleiche zwischen vielen Programmen sind - aber was wirklich ein Programm interessant macht , ist , wie es ist anders aus anderen Programmen.
Zusammenfassung
Entwurfsmuster sind fehlgeschlagen, weil:
quelle
Mustern fehlen Abstraktionen, einfache Muster werden abstrahiert, komplexe Muster werden nicht erkannt, daher sind Muster nicht nützlich (mit Ausnahme einiger weniger übergeordneter Muster).
Ich denke, Paul Graham sagte es am besten:
Wenn Sie ein Muster in Ihrem Code erkennen, bedeutet dies, dass sich etwas wiederholt, und Sie sollten eine bessere Abstraktion verwenden. Wenn Sie keine bessere Abstraktion haben, verwenden Sie das Muster als Problemumgehung. Da neuere Programmiersprachen bessere Abstraktionen liefern, werden Muster weniger nützlich.
Auch einfache Muster lassen sich oft leicht abstrahieren und komplexe Muster werden selten erkannt.
Wenn ein Muster durch eine Abstraktion ersetzt wird, bedeutet dies nicht, dass das Konzept hinter dem Muster verschwindet, sondern dass das Konzept explizit anstatt indirekt geschrieben werden kann und dass es im Vergleich zu anderem Code keine Besonderheiten mehr aufweist und nicht mehr als erkennbar ist ein Muster.
quelle
String.replace
Funktion hätten, könnten Sie sich vorstellen, dass sie als Muster auftaucht. Es ist jedoch besser, sie einmal zu schreiben, als sie weiterhin zu implementieren. Stimmen Sie zu, dass, wenn Sie diese Dinge nicht richtig benennen, das Lesen schwieriger wird, aber wenn es richtig gemacht wird, liest der Code deklarativer IMO (z. B. dergetOrElse
Stil von Optionsmonaden gegen Null-Prüfung)Während ich den Antworten der anderen weitgehend zustimme, glaube ich persönlich, dass ein Hauptgrund für eine nicht wachsende Anzahl von Mustern darin besteht, dass Muster ihre Bedeutung verlieren, wenn es unzählige gibt. Das Schöne an diesen wenigen Mustern ist, dass sie auf übliche Weise viele Problembereiche abdecken. Wenn Sie sich auf eine endlose Musterdomäne konzentrieren, haben Sie am Ende überhaupt kein Muster. Es ist ein bisschen wie "Wie lang ist die Küste einer Insel?". Wenn Sie auf einer Karte messen, kommen Sie mit einer anständigen Nummer. Wenn Sie jedoch versuchen, genauer zu werden und eine feinere Auflösung zu erzielen, werden Sie feststellen, dass die Länge immer mehr ins Unendliche steigt (oder die Unsicherheit; wie würden Sie die genaue Grenze mit Gezeiten und auf atomarer Ebene messen?).
quelle
Etwas, das in keiner der anderen Antworten erwähnt wird, das ebenfalls relevant ist:
Der Aufstieg dynamisch getippter Sprachen.
Als das Buch herauskam, gab es ernsthafte Diskussionen darüber, dass Java einfach zu langsam war, um echte Arbeit zu leisten. Heute wird Java aufgrund seiner Geschwindigkeit häufig in ausdrucksstärkeren Sprachen verwendet . Vielleicht sind Ruby, Python, JavaScript usw. für einige wichtige Anwendungsklassen immer noch zu langsam, aber im Großen und Ganzen sind sie für die meisten Zwecke schnell genug. Und JavaScript wird immer schneller, obwohl in jeder Version mehr Funktionen enthalten sind.
Das ursprüngliche GoF-Buch hatte die Muster sowohl in smalltalk als auch in c ++, und wenn Speicherplatz zur Verfügung steht, waren die Muster in smalltalk immer kürzer und manchmal bedeutend kürzer. Einige der Merkmale der klassischen Entwurfsmuster sind wirklich Möglichkeiten, einem statisch typisierten System dynamische Merkmale hinzuzufügen (wie die bereits diskutierte AbstractFactory, in der Sie die richtige Klasse basierend auf Laufzeitdaten instanziieren). Andere sind in dynamischen Sprachen so viel kürzer, dass sie sich einfach in den idiomatischen Gebrauch der Sprache selbst einfügen.
quelle
Es ist geschehen. Dutzende, wenn nicht sogar Hunderte von Büchern wurden veröffentlicht, um die gesamte Informatik auf Entwurfsmuster zu reduzieren, während Verleger und Autoren versuchten, einen weiteren Zug zu erobern (oder zu erschaffen). Ich habe ein Regal von ihnen. Nie konsultiert, seitdem ich das erste Mal gescannt habe, und ja, ich war ein Trottel, weil dort wenig oder gar nichts von tatsächlichem Nutzen war oder das noch nicht gut bekannt war (siehe zum Beispiel Typ Objekt, das nicht mehr als die dritte Normalform ist, die über ausgedrückt wird) ein Dutzend Seiten statt eines Absatzes), und weil offensichtlich je weniger Muster desto besser: Ein Punkt, der den meisten Praktizierenden entgangen ist. In der Tat, als ich eine Widerlegung von Type Object postete, wurde ich angewiesen, meinen Text als Entwurfsmuster umzugestalten.Wahre Geschichte. Was auch einen anderen Mangel des Projekts zeigt: kein Überprüfungs-, Ausschluss- oder Ablehnungsmechanismus.
Tatsächlich hat die GoF nicht wirklich versucht, "Design Patterns" gründlich zu erforschen. Vielmehr beschäftigten sie sich mit einem viel größeren Projekt: der Einführung von „Mustersprache“ in CS mit all seinen bizarren Notationen von Kräften, Teilnehmern usw., die schlichtweg scheiterten, weil sie von Grund auf falsch gedacht und auch sinnlos waren.
Was sie erreicht haben, was nützlich war, waren zwei Dinge:
Ein weiteres nützliches Konzept, das aufkam, war das "Anti-Pattern", z. B. "Log and Throw". Das Projekt wurde, wie viele Modeerscheinungen in CS, durch seine eigene Evangelisation und die irrtümliche Übernahme als eine weitere CS - Religion zum Scheitern verurteilt, und es ging den Weg der meisten dieser Religionen Fred Brooks (1965). Schade, dass wir das wirklich alle paar Jahre wieder entdecken müssen.
quelle
Es gab / gibt mehrere Bücher mit dem Titel PLoP ( Pattern Languages of Program Design ), bei denen es sich jeweils um eine Sammlung von Beiträgen handelt, die auf einer jährlichen Konferenz vorgestellt wurden .
Beim Lesen der Bücher stellte ich fest, dass einige Muster interessant und für mich neu waren, einige davon als Standard (z. B. "halbes Objekt plus Protokoll").
Nein, die Sammlung der GoF war nicht erschöpfend und inspirierte / inspiriert die Menschen, neue zu sammeln / zu beschreiben / zu entdecken / zu erfinden.
Die "nur 12 zusätzlichen Muster, die im Wikipedia-Artikel aufgeführt sind", sind vermutlich auch keine vollständige Sammlung: dh es gibt andere, die anderswo dokumentiert sind, z. B. in den PLoP-Büchern und vielleicht auch anderswo.
quelle
Das Buch Gang of Four (GoF) enthält die meisten Muster, die ein erfahrener Programmierer in einer nicht funktionalen Sprache im Werkzeuggürtel hat. Es ist wie die Basis-Tools, mit denen alle Builder vertraut sind. Der Hauptbeitrag des Buches bestand darin , den Mustern, die von den meisten erfahrenen Programmierern zu dieser Zeit gebräuchlich waren , einen genau definierten Namen zu geben und so die Kommunikation zwischen Programmierern zu unterstützen, die über Entwurfsoptionen diskutieren.
Sie erwarten, dass ein Elektriker einige Werkzeuge hat, die ein normaler Builder nicht hat. Ebenso erwarten Sie, dass ein WPF-Programmierer die Entwurfsmuster für "Abhängigkeitseigenschaften" oder ein "SQL-Programmierer" die Entwurfsmuster für die Verwendung von Triggern kennt Erstellen Sie Audit-Daten.
Wir betrachten diese jedoch nicht als „Entwurfsmuster“, da sie nur mit einer Technologie verwendet werden.
Einige weitere moderne Design Pattern-Bücher sind „Refactoring, Improving the Design of Existing Code (Martin Fowler)“ und „Clean Code: Ein Handbuch für agiles Software-Handwerk (Robert C. Martin) “. Beide Bücher präsentieren den Inhalt als Transformationen, die Sie vornehmen Nach Ihrem aktuellen Code und nicht als "vorkonfektioniertes wiederverwendbares Design", es handelt sich jedoch ebenso um "Designmuster".
quelle
Hier ist ein Interview mit Erich Gamma, in dem er über ihre Auswahl von Mustern nachdenkt und darüber, was sie heute ändern würden (heute wie vor 10 Jahren, haha).
http://www.informit.com/articles/article.aspx?p=1404056
quelle
Die tatsächlichen Muster in dem Buch sind manchmal wirklich nützlich, aber sie sind nur Beispiele für ein leistungsfähigeres Werkzeug, das das Buch Ihnen bietet: ein tiefes Verständnis, wann und wo es besser ist, monolithischen Code in unabhängige Teile zu schneiden, die durch eine Schnittstelle getrennt und geregelt werden .
Wenn Sie diese Fähigkeit erlernen, werden Sie feststellen, dass Sie sich nicht die genauen Details jedes einzelnen Musters merken müssen, da Sie die von Ihnen implementierte Lösung immer so schneiden können, wie es am besten zu ihrem Zweck passt. Die Idee, immer mehr Muster aufzuschreiben, erscheint daher sehr akademisch und sinnlos.
quelle
Das GoF-Buch und Wikipedia sind kaum die einzige Quelle bekannter Designmuster. Wenn Sie nur nach "Design Patterns" in Amazon.com suchen, erhalten Sie Hunderte von Büchern (versuchen Sie diese Suche ). Ich denke, sie listen nur das bekannteste Muster im Wikipedia-Artikel auf .
Das Problem ist also nicht, dass es nicht genügend dokumentierte Entwurfsmuster gibt. Vielmehr gibt es so viele, dass sich niemand alle merken kann und die meisten Programmierer nur wenige erkennen. Das große Versprechen der gemeinsamen Mustersprache bricht an dieser Stelle zusammen.
quelle
Es gibt wahrscheinlich viele Strukturen, an die noch nicht gedacht wurde. Solange Menschen Software entwickeln, werden Design-Herausforderungen zu bewältigen sein. Einige davon lassen sich möglicherweise mit cleveren neuen Mustern lösen, die andere verwenden könnten.
Programmiersprachen wurden entwickelt und weiterentwickelt, um die am häufigsten verwendeten Muster zu abstrahieren. Diese Muster existieren noch in der Gestaltung der Sprachen. Sie werden heute vielleicht ignoriert, aber das macht sie nicht unwichtig.
Ist das Wissen, wie man ein Haus baut, plötzlich unwichtig, wenn wir Roboter haben, die es für uns tun können? Ich würde nein argumentieren, ist es nicht. Es ist sicher weniger relevant - und wahrscheinlich auch weniger lohnend zu studieren, da die Nachfrage stark gesunken ist und niemand anderes es studiert.
Also nein, ich glaube nicht, dass der Musterraum, wie Sie ihn nennen, erschöpft ist. Wie eine andere Antwort hervorhob, ist es wahrscheinlich unendlich. Aber mit dem Nachlassen der Nachfrage nach Systemdesign, der Erhöhung unseres Abstraktionsturms und der Leistungsfähigkeit unserer Programmiersprachen werden immer weniger Leute, die sich auf den obersten Ebenen aufhalten, auf die Details des Turmbaus achten .
quelle
Muster sind unendlich. Sie können jedes Muster optimieren oder mischen, um neue zu erstellen. Enterprise-Integrationsmuster sind ebenfalls gut definiert für jede Domain entwickeln sich Muster und sie ändern sich auch für ausdrucksstarke Sprachen wie Python oder Scala.
quelle