design-patterns - patterns - factory pattern




Ersetzt funktionale Programmierung GoF-Designmuster? (16)

Ist die Behauptung wahr, dass funktionale Programmierung die Notwendigkeit von OOP-Entwurfsmustern eliminiert?

Funktionale Programmierung ist nicht dasselbe wie objektorientierte Programmierung. Objektorientierte Entwurfsmuster gelten nicht für die funktionale Programmierung. Stattdessen haben Sie funktionale Designmuster für die Programmierung.

Für die funktionale Programmierung werden Sie die OO-Designmusterbücher nicht lesen, Sie werden andere Bücher über FP-Entwurfsmuster lesen.

Sprache Agnostiker

Nicht völlig. Nur sprachunabhängig in Bezug auf OO-Sprachen. Die Entwurfsmuster gelten überhaupt nicht für prozedurale Sprachen. Sie sind in einem relationalen Datenbankentwurfskontext kaum sinnvoll. Sie gelten nicht beim Entwerfen einer Tabelle.

ein typisches OOP-Designmuster und sein funktionales Äquivalent?

Das obige sollte nicht existieren. Das ist, als ob man nach einem Stück Verfahrenscode fragt, der als OO-Code umgeschrieben wird. Ummm ... Wenn ich das ursprüngliche Fortran (oder C) in Java übersetze, habe ich nichts mehr getan, als es zu übersetzen. Wenn ich es komplett in ein OO-Paradigma umschreibe, sieht es nicht mehr so ​​aus wie das Original Fortran oder C - es wird nicht mehr erkennbar sein.

Es gibt keine einfache Zuordnung von OO Design zu funktionalem Design. Sie sind sehr unterschiedliche Sichtweisen auf das Problem.

Funktionale Programmierung (wie alle Programmierstile) hat Entwurfsmuster. Relationale Datenbanken haben Entwurfsmuster, OO hat Entwurfsmuster, prozedurale Programmierung hat Entwurfsmuster. Alles hat Designmuster, sogar die Architektur von Gebäuden.

Entwurfsmuster - als Konzept - sind ein zeitloser Weg des Aufbaus, unabhängig von Technologie oder Problembereich. Für bestimmte Problembereiche und Technologien gelten jedoch spezifische Entwurfsmuster.

Jeder, der darüber nachdenkt, was er tut, wird Designmuster entdecken.

Seit ich letztes Jahr F # und OCaml gelernt habe, habe ich eine große Anzahl von Artikeln gelesen, die darauf bestehen, dass Design Patterns (speziell in Java) eine Lösung für die fehlenden Features in Imperativ-Sprachen darstellen. Ein Artikel, den ich gefunden habe, macht einen ziemlich starken Anspruch :

Die meisten Leute, die ich getroffen habe, haben das Design Patterns Buch der Gang of Four gelesen. Jeder Programmierer, der sich selbst respektiert, wird Ihnen sagen, dass das Buch sprachunabhängig ist und die Muster für das Software-Engineering im Allgemeinen gelten, unabhängig davon, welche Sprache Sie verwenden. Dies ist eine noble Behauptung. Leider ist es weit von der Wahrheit entfernt.

Funktionale Sprachen sind äußerst ausdrucksstark. In einer funktionalen Sprache braucht man keine Entwurfsmuster, weil die Sprache wahrscheinlich so hoch ist, dass man schließlich in Konzepten programmiert, die Entwurfsmuster alle zusammen eliminieren.

Die Hauptmerkmale der funktionalen Programmierung sind Funktionen wie erstklassige Werte, Curry, unveränderliche Werte usw. Es scheint mir nicht offensichtlich zu sein, dass sich OO-Entwurfsmuster an all diese Merkmale annähern.

Außerdem scheint es mir in funktionalen Sprachen, die OOP unterstützen (wie F # und OCaml), offensichtlich, dass Programmierer, die diese Sprachen verwenden, die gleichen Entwurfsmuster verwenden würden, die für jede andere OOP-Sprache verfügbar sind. Tatsächlich verwende ich jeden Tag F # und OCaml, und es gibt keine auffallenden Unterschiede zwischen den Mustern, die ich in diesen Sprachen verwende, und den Mustern, die ich benutze, wenn ich in Java schreibe.

Ist die Behauptung wahr, dass funktionale Programmierung die Notwendigkeit von OOP-Entwurfsmustern eliminiert? Wenn ja, könnten Sie ein Beispiel für ein typisches OOP-Entwurfsmuster und dessen funktionales Äquivalent posten oder verlinken?


Brians Kommentare über die enge Verbindung zwischen Sprache und Muster sind auf den Punkt gebracht,

Der fehlende Teil dieser Diskussion ist das Konzept des Idioms. Copliens Buch "Advanced C ++" hatte hier einen großen Einfluss. Lange bevor er Christopher Alexander und die Kolumne ohne Namen entdeckte (und man kann nicht vernünftig über Muster sprechen, ohne Alexander zu lesen), sprach er darüber, wie wichtig es ist, Idiom zu beherrschen, um wirklich eine Sprache zu lernen. Er benutzte String-Kopie in C als Beispiel, während (* von ++ = * bis ++); Sie können dies als einen Bandaid für ein fehlendes Sprachfeature (oder Bibliotheksfeature) sehen, aber was wirklich wichtig ist, ist, dass es eine größere Einheit des Denkens oder des Ausdrucks ist als alle seine Teile.

Das ist es, was Muster und Sprachen zu tun versuchen, damit wir unsere Absichten deutlicher ausdrücken können. Je reicher die Einheiten des Denkens sind, desto komplexer können die Gedanken sein, die du ausdrücken kannst. Ein reichhaltiges, gemeinsames Vokabular auf verschiedenen Skalen - von der Systemarchitektur bis zum Bit-Twiddling - ermöglicht uns intelligentere Gespräche und Gedanken darüber, was wir tun sollten.

Wir können auch als Individuen lernen. Was ist der ganze Sinn der Übung? Wir alle können Dinge verstehen und anwenden, die wir niemals selbst denken könnten. Sprachen, Frameworks, Bibliotheken, Muster, Idiome usw. haben ihren Platz darin, den intellektuellen Reichtum zu teilen.


Der von Ihnen zitierte Blogpost übertreibt seinen Anspruch ein wenig. FP beseitigt nicht die Notwendigkeit von Entwurfsmustern. Der Begriff "Entwurfsmuster" wird nur selten in FP-Sprachen verwendet. Aber sie existieren. Funktionale Sprachen haben viele Best Practice-Regeln der Form "wenn Sie auf Problem X stoßen, verwenden Sie Code, der wie Y aussieht", was im Grunde ein Designmuster ist.

Es ist jedoch richtig, dass die meisten OOP-spezifischen Entwurfsmuster in funktionalen Sprachen ziemlich irrelevant sind.

Ich finde es nicht besonders kontrovers zu sagen, dass Designmuster im Allgemeinen nur dazu dienen, Defizite in der Sprache zu beheben. Und wenn eine andere Sprache das gleiche Problem trivial lösen kann, braucht diese andere Sprache kein Designmuster dafür. Benutzer dieser Sprache sind sich vielleicht nicht einmal bewusst, dass das Problem existiert , weil es in dieser Sprache kein Problem gibt.

Hier ist, was die Viererbande zu diesem Thema zu sagen hat:

Die Wahl der Programmiersprache ist wichtig, weil sie den Blickwinkel beeinflusst. Unsere Muster gehen von Smalltalk / C ++ - Sprachfunktionen aus, und diese Auswahl bestimmt, was einfach implementiert werden kann und was nicht. Wenn wir prozedurale Sprachen angenommen haben, könnten wir Designmuster namens "Vererbung", "Verkapselung" und "Polymorphismus" einbezogen haben. In ähnlicher Weise werden einige unserer Muster direkt von den weniger gebräuchlichen objektorientierten Sprachen unterstützt. CLOS hat zum Beispiel mehrere Methoden, die die Notwendigkeit eines Musters wie Visitor verringern. In der Tat gibt es genug Unterschiede zwischen Smalltalk und C ++, was bedeutet, dass einige Muster einfacher in einer Sprache ausgedrückt werden können als die andere. (Siehe Iterator zum Beispiel.)

(Das obige Zitat stammt aus dem Buch Introduction to the Design Patterns, Seite 4, Absatz 3)

Die Hauptmerkmale der funktionalen Programmierung sind Funktionen wie erstklassige Werte, Curry, unveränderliche Werte usw. Es scheint mir nicht offensichtlich zu sein, dass sich OO-Entwurfsmuster an all diese Merkmale annähern.

Was ist das Befehlsmuster, wenn nicht eine Annäherung an erstklassige Funktionen? :) In einer FP-Sprache würden Sie einfach eine Funktion als Argument an eine andere Funktion übergeben. In einer OOP-Sprache müssen Sie die Funktion in einer Klasse einbinden, die Sie instanziieren und dann an die andere Funktion übergeben können. Der Effekt ist der gleiche, aber in OOP wird es ein Design-Muster genannt, und es braucht viel mehr Code. Und was ist das abstrakte Fabrikmuster, wenn nicht currying? Übergeben Sie die Parameter einer Funktion jeweils einzeln, um zu konfigurieren, welche Art von Wert ausgegeben wird, wenn Sie sie schließlich aufrufen.

Ja, mehrere GoF-Designmuster werden in FP-Sprachen überflüssig, weil es leistungsfähigere und einfacher zu verwendende Alternativen gibt.

Aber natürlich gibt es immer noch Entwurfsmuster, die nicht durch FP-Sprachen gelöst werden. Was ist das FP-Äquivalent eines Singleton? (Einen Moment außer Acht lassend, dass Singletons im Allgemeinen ein schreckliches Muster zu verwenden sind)

Und es funktioniert auch in beide Richtungen. Wie gesagt, FP hat auch seine Entwurfsmuster, die Leute denken normalerweise nicht an sie.

Aber du hast vielleicht Monaden überfahren. Was sind sie, wenn nicht ein Entwurfsmuster für den "Umgang mit dem globalen Staat"? Das ist ein Problem, das in OOP-Sprachen so einfach ist, dass dort kein gleichwertiges Designmuster existiert.

Wir brauchen kein Entwurfsmuster für "Inkrementiere eine statische Variable" oder "Lese von diesem Sockel", weil es genau das ist, was du tust .

In (reinen) funktionalen Sprachen sind Nebenwirkungen und ein veränderbarer Zustand unmöglich, es sei denn, man arbeitet mit dem "Entwurfsmuster" der Monade oder mit irgendeiner anderen Methode, um dasselbe zu ermöglichen.

Außerdem scheint es mir in funktionalen Sprachen, die OOP unterstützen (wie F # und OCaml), offensichtlich, dass Programmierer, die diese Sprachen verwenden, die gleichen Entwurfsmuster verwenden würden, die für jede andere OOP-Sprache verfügbar sind. Tatsächlich benutze ich momentan F # und OCaml, und es gibt keine auffallenden Unterschiede zwischen den Mustern, die ich in diesen Sprachen verwende, und den Mustern, die ich benutze, wenn ich in Java schreibe.

Vielleicht weil du immer noch zwingend denkst? Viele Menschen, die ihr ganzes Leben lang mit Imperativsprachen zu tun hatten, haben es schwer, diese Gewohnheit aufzugeben, wenn sie eine funktionale Sprache ausprobieren. (Ich habe einige ziemlich witzige Versuche bei F # gesehen, bei denen buchstäblich jede Funktion nur eine Folge von 'let'-Anweisungen war, im Grunde genommen als hätte man ein C-Programm genommen und alle Semikolons durch' let 'ersetzt. :))

Eine andere Möglichkeit wäre, dass Sie nicht erkannt haben, dass Sie Probleme trivial lösen, die Entwurfsmuster in einer OOP-Sprache erfordern würden.

Wenn Sie currying verwenden oder eine Funktion als Argument an eine andere übergeben, halten Sie inne und überlegen Sie sich, wie Sie das in einer OOP-Sprache tun würden.

Ist die Behauptung wahr, dass funktionale Programmierung die Notwendigkeit von OOP-Entwurfsmustern eliminiert?

Ja. :) Wenn Sie in einer FP-Sprache arbeiten, benötigen Sie nicht mehr die OOP-spezifischen Entwurfsmuster. Aber Sie brauchen immer noch einige allgemeine Entwurfsmuster, wie MVC oder andere nicht-OOP-spezifische Sachen, und Sie brauchen stattdessen ein paar neue FP-spezifische "Entwurfsmuster". Alle Sprachen haben ihre Unzulänglichkeiten, und Entwurfsmuster sind normalerweise, wie wir um sie arbeiten.

Wie auch immer, Sie werden es vielleicht interessant finden, sich an "sauberen" FP-Sprachen zu versuchen, wie ML (mein persönlicher Favorit, zumindest für Lernzwecke), oder Haskell, wo Sie nicht die OOP-Krücke haben, auf die Sie zurückgreifen können stehen vor etwas Neuem.

Wie erwartet, widersprachen einige Leute meiner Definition von Entwurfsmustern als "Flicken von Mängeln in einer Sprache", also hier meine Rechtfertigung: Wie bereits gesagt, sind die meisten Entwurfsmuster für ein Programmierparadigma oder manchmal sogar für eine bestimmte Sprache spezifisch. Oft lösen sie Probleme, die nur in diesem Paradigma existieren (siehe Monaden für FP oder abstrakte Fabriken für OOP). Warum existiert das abstrakte Fabrikmuster nicht in FP? Weil das Problem, das es zu lösen versucht, dort nicht existiert. Wenn also ein Problem in OOP-Sprachen existiert, das in FP-Sprachen nicht existiert, dann ist dies eindeutig ein Mangel der OOP-Sprachen. Das Problem kann gelöst werden, aber Ihre Sprache tut dies nicht, aber Sie benötigen eine Menge Vorabcode von Ihnen, um es zu umgehen. Idealerweise möchten wir, dass unsere Programmiersprache alle Probleme auf magische Weise beseitigt. Jedes noch bestehende Problem ist im Prinzip ein Mangel der Sprache. ;)


Die GoF Design Patterns codieren Workaround-Rezepte für OO-Sprachen, die von Simula 67 abstammen, wie Java und C ++.

Die meisten der "Übel", die von den Entwurfsmustern behandelt werden, sind verursacht durch:

  • statisch typisierte Klassen, die Objekte angeben, aber selbst keine Objekte sind;
  • Beschränkung auf Single-Dispatch (nur das Argument ganz links wird zur Auswahl einer Methode verwendet, die restlichen Argumente werden nur als statische Typen betrachtet: Wenn sie dynamische Typen haben, liegt es an der Methode, das mit ad-hoc-Ansätzen zu sortieren);
  • Unterscheidung zwischen regulären Funktionsaufrufen und objektorientierten Funktionsaufrufen, dh objektorientierte Funktionen können nicht als Funktionsargumente übergeben werden, bei denen normale Funktionen erwartet werden und umgekehrt; und
  • Unterscheidung zwischen "Basistypen" und "Klassentypen".

Es gibt kein einziges dieser Entwurfsmuster, das nicht im Common Lisp Object System verschwindet, obwohl die Lösung im Wesentlichen genauso strukturiert ist wie im entsprechenden Entwurfsmuster. (Dieses Objektsystem geht dem GoF-Buch weit über ein Jahrzehnt voraus. Common Lisp wurde im selben Jahr, in dem dieses Buch erstmals veröffentlicht wurde, ein ANSI-Standard.)

Was die funktionale Programmierung betrifft, hängt es davon ab, ob die gegebene funktionale Programmiersprache irgendeine Art von Objektsystem hat und ob sie nach den Objektsystemen modelliert ist, die von den Mustern profitieren. Diese Art von Objektorientierung passt nicht gut zur funktionalen Programmierung, weil die Mutation des Zustands an der Front und im Zentrum steht.

Konstruktion und nicht mutierender Zugriff sind mit funktionaler Programmierung kompatibel, und so könnten Muster, die mit abstrahiertem Zugriff oder Konstruktion zu tun haben, anwendbar sein: Muster wie Fabrik, Fassade, Proxy, Dekorateur, Besucher.

Auf der anderen Seite, die Verhaltensmuster wie Staat und Strategie wahrscheinlich nicht direkt in funktionalen OOP, weil Mutation des Staates ist in ihrem Kern. Dies bedeutet nicht, dass sie nicht gelten; vielleicht wenden sie sich irgendwie in Kombination mit den Tricks an, die für die Simulation des veränderlichen Zustands zur Verfügung stehen.



Ich denke, dass jedes Paradigma einem anderen Zweck dient und als solches nicht auf diese Weise verglichen werden kann.

Ich habe nicht gehört, dass die GoF-Designmuster auf jede Sprache anwendbar sind. Ich habe gehört, dass sie auf alle OOP-Sprachen anwendbar sind. Wenn Sie die Funktionale Programmierung verwenden, unterscheidet sich die Problemdomäne von OO-Sprachen.

Ich würde keine funktionale Sprache verwenden, um eine Benutzeroberfläche zu schreiben, aber eine der OO-Sprachen wie C # oder Java würde diesen Job erleichtern. Wenn ich eine funktionale Sprache schreiben würde, würde ich OO Design Patterns nicht in Betracht ziehen.


Ich würde gerne ein paar exzellente, aber etwas dichte Arbeiten von Jeremy Gibbons vorstellen: "Entwurfsmuster als höherwertige generische Programme" und "Die Essenz des Iterator-Musters" (beide hier verfügbar: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Diese beschreiben beide, wie idiomatische funktionale Konstrukte das Terrain abdecken, das durch spezifische Entwurfsmuster in anderen (objektorientierten) Einstellungen abgedeckt wird.


Ich würde sagen, wenn Sie eine Sprache wie Lisp mit ihrer Unterstützung für Makros haben, dann können Sie eigene domänenspezifische Abstraktionen erstellen, Abstraktionen, die oft viel besser sind als die allgemeinen Idiomlösungen.


In dem neuen Buch mit dem Titel "Functional Programming Patterns - in Scala und Clojure" hat der Autor Michael.B. Linn macht in vielen Fällen einen ordentlichen Job beim Vergleichen und Bereitstellen von Ersatz für die GoF-Muster und diskutiert auch die neueren funktionalen Muster wie "Schwanzrekursion", "Memoisierung", "Lazy Sequence" usw.

Dieses Buch ist bei Amazon erhältlich. Ich fand es sehr informativ und ermutigend, wenn ich aus einem OO-Hintergrund von ein paar Jahrzehnten komme.


Muster sind Wege, ähnliche Probleme zu lösen, die immer wieder gesehen und dann beschrieben und dokumentiert werden. Also nein, FP wird keine Muster ersetzen; FP kann jedoch neue Muster erstellen und einige aktuelle "Best Practices" -Muster "veraltet" machen.


OOP und FP haben unterschiedliche Ziele, OOP zielt darauf ab, die Komplexitäten / beweglichen Teile von Softwarekomponenten zu kapseln und FP zielt darauf ab, die Komplexität und Abhängigkeiten von Softwarekomponenten zu minimieren, aber diese 2 Paradigmen sind nicht unbedingt 100% widersprüchlich und könnten gemeinsam angewendet werden aus beiden Welten. Selbst mit einer Sprache, die keine funktionale Programmierung wie C # unterstützt, könnten Sie Funktionscode schreiben, wenn Sie die FP-Prinzipien verstehen. Ebenso können Sie OOP-Prinzipien mit F # anwenden, wenn Sie OOP-Prinzipien, Muster und Best Practices verstehen. Sie treffen die richtige Wahl aufgrund der Situation und des Problems, das Sie zu lösen versuchen, unabhängig von der verwendeten Programmiersprache.


OOP und die GoF-Muster befassen sich mit Staaten. OOP modelliert die Realität, um die Codebasis so nah wie möglich an den gegebenen Realitätsanforderungen zu halten. GoF-Entwurfsmuster sind Muster, die identifiziert wurden, um atomare Probleme in der realen Welt zu lösen. Sie behandeln das Problem des Staates auf eine semantische Art und Weise.

Da in der realen funktionalen Programmierung kein Zustand existiert, ist es nicht sinnvoll, die GoF-Muster anzuwenden. Es gibt keine funktionalen Designmuster auf die gleiche Weise wie GoF-Designmuster. Jedes funktionale Designmuster ist künstlich im Gegensatz zur Realität, da Funktionen Konstrukte von Mathematik und nicht Realität sind.

Funktionen fehlen das Konzept der Zeit, da sie immer den gleichen Wert haben, egal wie die aktuelle Zeit ist, es sei denn, Zeit ist Teil der Funktionsparameter, was es wirklich schwierig macht, "zukünftige Anfragen" zu verarbeiten. Hybride Sprachen, die diese Konzepte kombinieren, machen die Sprachen zu keinen echten funktionalen Programmiersprachen.

Funktionale Sprachen steigen nur wegen einer Sache: den gegenwärtigen natürlichen Restriktionen der Physik. Die heutigen Prozessoren sind aufgrund physikalischer Gesetze in ihrer Verarbeitungsgeschwindigkeit eingeschränkt. Sie sehen eine Stagnation der Taktfrequenz, aber eine Erweiterung der Prozessorkerne. Deshalb wird die Parallelität von Anweisungen immer wichtiger, um die Geschwindigkeit moderner Anwendungen zu erhöhen. Da die funktionale Programmierung definitionsgemäß keinen Zustand hat und daher keine Nebenwirkungen hat, ist es sicher, Funktionen parallel sicher zu verarbeiten.

GoF-Muster sind nicht veraltet. Sie sind mindestens notwendig, um die realen Anforderungen zu modellieren. Aber wenn Sie eine funktionale Programmiersprache verwenden, müssen Sie sie in ihre hybriden Entsprechungen umwandeln. Schließlich haben Sie keine Chance, nur funktionelle Programme zu erstellen, wenn Sie Persistenz verwenden. Für die hybriden Elemente Ihres Programms bleibt die Notwendigkeit, GoF-Muster zu verwenden. Jedes andere Element, das rein funktional ist, benötigt keine GoF-Muster, weil es keinen Zustand gibt.

Da das GoF-Muster für eine echte funktionale Programmierung nicht notwendig ist, bedeutet dies nicht, dass die SOLID-Prinzipien nicht angewendet werden sollten. Die SOLID-Prinzipien sind jenseits jedes Sprachparadigmas.


Und selbst die OO Design Pattern-Lösungen sind sprachenspezifisch. Entwurfsmuster sind Lösungen für häufige Probleme, die Ihre Programmiersprache nicht für Sie löst. In Java löst das Singleton-Muster das Problem der Eindeutigkeit (vereinfacht). In Scala haben Sie ein Konstrukt der obersten Ebene namens Object zusätzlich zur Klasse. Es ist instanziiert instanziiert und es gibt nur einen. Sie müssen das Singleton-Muster nicht verwenden, um einen Singleton zu erhalten. Es ist ein Teil der Sprache.


Wenn Sie versuchen, dies auf der Ebene von "Entwurfsmustern" (allgemein) und "FP versus OOP" zu betrachten, werden die Antworten, die Sie finden, bestenfalls trübe sein.

Gehen Sie jedoch auf beiden Achsen tiefer und beachten Sie spezifische Designmuster und spezifische Sprachmerkmale und Dinge werden klarer.

So ändern sich zum Beispiel bestimmte Muster wie Visitor , Strategy , Command und Observer definitiv, wenn sie eine Sprache mit algebraischen Datentypen und Pattern-Matching , Closures , First-Class-Funktionen usw. verwenden. Einige andere Muster aus dem GoF-Buch noch "Bleib doch".

Im Allgemeinen würde ich sagen, dass bestimmte Muster im Laufe der Zeit durch neue (oder gerade steigende) Sprachmerkmale eliminiert werden. Dies ist der natürliche Verlauf des Sprachdesigns; Wenn Sprachen zu einem höheren Niveau werden, werden Abstraktionen, die bisher nur in einem Buch mit Beispielen aufgerufen werden konnten, nun zu Anwendungen eines bestimmten Sprachmerkmals oder einer bestimmten Bibliothek.

(Nebenbei, hier ist ein neuer Blog, den ich geschrieben habe, der weitere Links zu weiteren Diskussionen über FP- und Design-Patterns enthält.)


Wie die angenommene Antwort sagte, haben OOP und FP alle ihre spezifischen Muster.

Es gibt jedoch einige Muster, die so verbreitet sind, dass alle Programmierplattformen, an die ich denken kann, haben sollten. Hier ist eine (unvollständige) Liste:

  • Adapter. Ich kann mir kaum eine nützliche Programmierplattform vorstellen, die so umfassend (und selbst erfüllt) ist, dass sie nicht mit der Welt reden muss. Wenn dies der Fall ist, wird definitiv ein Adapter benötigt.

  • Fassade. Jede Programmierplattform, die großen Quellcode verarbeiten kann, sollte modularisiert werden können. Wenn Sie ein Modul für andere Teile des Programms erstellen, sollten Sie die "schmutzigen" Teile des Codes ausblenden und ihm eine schöne Oberfläche geben.

  • Dolmetscher. Im Allgemeinen macht jedes Programm nur zwei Dinge: Parsing-Eingabe und Druckausgabe. Mauseingaben müssen analysiert werden, und Fensterwidgets müssen ausgedruckt werden. Daher bietet ein eingebetteter Interpreter dem Programm zusätzliche Möglichkeiten, Dinge anzupassen.

Außerdem habe ich bemerkt, dass in einer typischen FP-Sprache, Haskell, etwas ähnliches zu GoF-Mustern ist, aber mit anderen Namen. Meiner Meinung nach deutet dies darauf hin, dass sie da waren, weil es in FP- und OOP-Sprachen einige gemeinsame Probleme zu lösen gibt.

  • Monad Transformator und Dekorateur. Erstere fügt einer vorhandenen Monade zusätzliche Fähigkeiten hinzu, letztere fügen einem vorhandenen Objekt zusätzliche Fähigkeiten hinzu.





functional-programming