Funktionale Programmierung vs objektorientierte Programmierung [geschlossen]

Ich war bisher hauptsächlich mit OO-Programmierung vertraut und freue mich darauf, eine funktionale Sprache zu lernen. Meine Fragen sind:

• Wann wählen Sie funktionale Programmierung gegenüber objektorientiert?
• Was sind die typischen Problemdefinitionen, bei denen funktionale Programmierung die bessere Wahl ist?

Wann wählen Sie funktionale Programmierung gegenüber objektorientiert?

Wenn Sie eine andere Art der Softwareentwicklung erwarten:

• Objektorientierte Sprachen sind gut, wenn Sie einen festen Satz von Operationen für Dinge haben und wenn sich Ihr Code weiterentwickelt, fügen Sie hauptsächlich neue Dinge hinzu. Dies kann erreicht werden, indem neue Klassen hinzugefügt werden, die vorhandene Methoden implementieren, und die vorhandenen Klassen werden in Ruhe gelassen.

• Funktionale Sprachen sind gut, wenn Sie einen festen Satz von Dingen haben und wenn sich Ihr Code weiterentwickelt, fügen Sie hauptsächlich neue Operationen für vorhandene Dinge hinzu. Dies kann erreicht werden, indem neue Funktionen hinzugefügt werden, die mit vorhandenen Datentypen rechnen, und die vorhandenen Funktionen bleiben in Ruhe.

Wenn die Evolution in die falsche Richtung geht, haben Sie Probleme:

• Das Hinzufügen einer neuen Operation zu einem objektorientierten Programm erfordert möglicherweise das Bearbeiten vieler Klassendefinitionen, um eine neue Methode hinzuzufügen.

• Das Hinzufügen einer neuen Art von Dingen zu einem Funktionsprogramm erfordert möglicherweise das Bearbeiten vieler Funktionsdefinitionen, um einen neuen Fall hinzuzufügen.

Dieses Problem ist seit vielen Jahren bekannt. 1998 nannte Phil Wadler es das "Ausdrucksproblem" . Obwohl einige Forscher der Meinung sind, dass das Ausdrucksproblem mit Sprachmerkmalen wie Mixins angegangen werden kann, muss eine allgemein akzeptierte Lösung erst noch den Mainstream erreichen.

Was sind die typischen Problemdefinitionen, bei denen funktionale Programmierung die bessere Wahl ist?

Funktionale Sprachen zeichnen sich durch die Manipulation symbolischer Daten in Baumform aus. Ein beliebtes Beispiel sind Compiler, bei denen sich Quell- und Zwischensprachen selten ändern (meistens die gleichen Dinge ), aber Compiler-Autoren immer neue Übersetzungen und Codeverbesserungen oder -optimierungen hinzufügen (neue Operationen an Dingen). Kompilierung und Übersetzung sind im Allgemeinen "Killer-Apps" für funktionale Sprachen.

Sie müssen sich nicht unbedingt zwischen den beiden Paradigmen entscheiden. Sie können Software mit einer OO-Architektur unter Verwendung vieler Funktionskonzepte schreiben. FP und OOP sind orthogonaler Natur .

Nehmen Sie zum Beispiel C #. Man könnte sagen, es ist meistens OOP, aber es gibt viele FP-Konzepte und -Konstrukte. Wenn Sie Linq betrachten , sind die wichtigsten Konstrukte, die die Existenz von Linq ermöglichen, funktionaler Natur: Lambda-Ausdrücke .

Ein weiteres Beispiel, F #. Man könnte sagen, es ist hauptsächlich FP, aber es gibt viele OOP-Konzepte und -Konstrukte. Sie können Klassen, abstrakte Klassen und Schnittstellen definieren und sich mit Vererbung befassen. Sie können die Veränderbarkeit sogar verwenden, wenn dadurch Ihr Code klarer wird oder wenn die Leistung erheblich gesteigert wird.

Viele moderne Sprachen sind Multi-Paradigmen.

Empfohlene Lesungen

Da ich im selben Boot bin (OOP-Hintergrund, FP lernen), würde ich Ihnen einige Lesungen vorschlagen, die ich sehr geschätzt habe:

• Funktionale Programmierung für die tägliche .NET-Entwicklung von Jeremy Miller. Ein großartiger Artikel (obwohl schlecht formatiert), der viele Techniken und praktische Beispiele für FP auf C # zeigt.

• Real-World Functional Programming von Tomas Petricek. Ein großartiges Buch, das sich hauptsächlich mit FP-Konzepten befasst und versucht zu erklären, was sie sind, wann sie verwendet werden sollten. Es gibt viele Beispiele in F # und C #. Auch Petriceks Blog ist eine großartige Informationsquelle.

Objektorientierte Programmierung bietet:

1. Verkapselung, zu
   • Kontrollmutation des inneren Zustands
   • Kopplung an interne Darstellung begrenzen
2. Subtyping, erlaubt:
   • Substitution kompatibler Typen (Polymorphismus)
   • ein grobes Mittel zum Teilen der Implementierung zwischen Klassen (Implementierungsvererbung)

Die funktionale Programmierung in Haskell oder sogar in Scala kann die Substitution durch allgemeinere Mechanismen von Typklassen ermöglichen. Der veränderbare innere Zustand wird entweder entmutigt oder verboten. Die Kapselung der internen Repräsentation kann ebenfalls erreicht werden. Siehe Haskell vs OOP für einen guten Vergleich.

Normans Behauptung, dass "das Hinzufügen einer neuen Art von Dingen zu einem Funktionsprogramm möglicherweise das Bearbeiten vieler Funktionsdefinitionen erfordert, um einen neuen Fall hinzuzufügen." hängt davon ab, wie gut der Funktionscode Typklassen verwendet hat. Wenn die Musterübereinstimmung für einen bestimmten abstrakten Datentyp über eine Codebasis verteilt ist, leiden Sie zwar unter diesem Problem, aber es ist möglicherweise zunächst ein schlechtes Design.

BEARBEITET Verweis auf implizite Konvertierungen bei der Erörterung von Typklassen entfernt. In Scala werden Typklassen mit impliziten Parametern und nicht mit Konvertierungen codiert, obwohl implizite Konvertierungen ein weiteres Mittel sind, um die Substitution kompatibler Typen zu erreichen.

1. Wenn Sie sich in einer stark gleichzeitigen Umgebung befinden, ist eine reine funktionale Programmierung hilfreich. Das Fehlen eines veränderlichen Zustands macht die Parallelität fast trivial. Siehe Erlang.

2. In einer Multiparadigmensprache möchten Sie möglicherweise einige Dinge funktional modellieren, wenn das Vorhandensein eines veränderlichen Zustands ein Implementierungsdetail sein muss und FP daher ein gutes Modell für die Problemdomäne ist. Siehe beispielsweise Listenverständnisse in Python oder std.range in der Programmiersprache D. Diese sind von der funktionalen Programmierung inspiriert.