Hallo Habr! Ich präsentiere Ihnen eine Übersetzung eines Artikels von
Roman Provaznik -
Warum ist FP selbst für OOP-Entwickler wichtig?Als ich mich sehr für funktionale Programmierung interessierte, begann ich sie zu studieren und allen meinen Freunden zu erzählen, wie wunderbar sie ist. Später stieß ich auf einen Artikel über funktionale Programmierung aus der Sicht eines OOP-Programmierers und beschloss, ihn für Sie zu übersetzen. Beurteilen Sie nicht streng, dies ist meine erste Übersetzung.
Ich wurde gebeten, eine persönliche Meinung zur funktionalen Programmierung aus objektiv orientierter Sicht abzugeben. Ich war sogar gezwungen, ein Konto auf dem Medium zu erstellen. Als ehemaliger OOP-Entwickler und im Moment werde ich eines Tages ein echter FP-Programmierer. Ich glaube, ich habe etwas zu sagen:
Willkommen Reisender
Wenn Sie die letzten 60 Jahre nicht auf einem anderen Planeten verbracht haben (wenn ja, willkommen zurück, Reisender), haben Sie wahrscheinlich von funktionaler Programmierung gehört. Wenn Sie aktuellen Trends in der Softwareindustrie folgen, hören Sie täglich Begriffe wie „funktionale Programmierung“, „Unveränderlichkeit“, „reine Funktionen“ und „Komposition“. All dies klingt cool, entzückend und verständlich, bis Sie denken: "Hey, ich bin ein OOP-Programmierer und kann (oder will nicht) das Paradigma ändern. Was kann mir funktionale Programmierung geben? Warum sollte ich mich darum kümmern? " Als FP-Programmierer / Enthusiast aus der OOP-Welt möchte ich mitteilen, was ich selbst vor vielen Jahren gerne wissen würde. Sie können stundenlang darüber sprechen, also lassen Sie uns die drei wichtigsten Dinge auswählen.
Unveränderlichkeit
Der traditionelle Vorteil von FP ist das Wort, das normalerweise mindestens zwei Folien jeder Präsentation über funktionale Programmierung enthält. FP Silberkugel, richtig? Nicht wirklich. Trotz der Tatsache, dass dieses Wort am häufigsten von funktionalen Programmierern verwendet wird, ist es nicht ausschließlich für FP. Als OOP-Entwickler können Sie (fast) das gleiche Maß an Unveränderlichkeit erreichen wie ein FP-Entwickler. In der Tat ist dies einfach genug, Sie müssen Ihre Objekte und Sammlungen nur ein wenig anders betrachten. Stellen Sie sich vor, Sie ändern nicht das Original, sondern erstellen eine neue Version. Artikel zur Sammlung hinzugefügt? Großartig! Sie haben die ursprüngliche Sammlung nicht geändert, sondern nur eine neue Sammlung mit dem hinzugefügten Element. Die Eigenschaft eines Objekts geändert? Wow! Jetzt haben Sie ein neues Objekt mit einer geänderten Eigenschaft.
Ich weiß, ich weiß - es klingt seltsam. Aber dieser kleine Bewusstseinswechsel ermöglicht es Ihnen, ruhiger zu schlafen. Sobald Sie verstehen, dass Ihre Objekte nicht geändert (nur kopiert) werden können, können Sie sicher sein, dass niemand im Team sie an anderer Stelle neu zuweisen kann. Es ist, als ob Sie Ihre alte Lieblings-Pink Floyd-Audiokassette ausleihen, ohne befürchten zu müssen, dass sie mit Justin Bieber neu aufgenommen wird. Als Bonus verfügt Ihr Code über vollständig nachvollziehbare Methoden, mit denen echte Änderungen vorgenommen werden (bei denen neue Objekte basierend auf den ursprünglichen Objekten erstellt werden). Und ich hätte fast vergessen, dass Sie als C # - oder Java-Entwickler diese bereits verwenden, indem Sie "ToLower ()", "Trim ()" in Zeilen aufrufen, die anfangs unveränderlich sind. Das ist im Wesentlichen nichts Neues.
Reine Funktionen
Eine andere modische Phrase, die fälschlicherweise ausschließlich als FP betrachtet wird. Was ist eine „reine Funktion“? Einfach ausgedrückt ist eine reine Funktion eine Funktion, die das gleiche Ergebnis mit dem gleichen Eingabewert ohne Kommunikation mit der „Außenwelt“ (E / A-Operationen, allgemeiner Status usw.) zurückgibt, die auch als „Nebenwirkungen“ bezeichnet wird. Ein typisches Beispiel für diese Art von Funktion kann das Abrufen der Zeichenfolgenlänge (Sie stellen keine Verbindung zur Datenbank her, um die Anzahl der Zeichen in einer Zeichenfolge zu zählen?), Das Berechnen des Sinus usw. sein. Was sind die Vorteile für OOP? Gleich wie bei FP. Wenn Sie mit reinen Funktionen (oder Methoden) arbeiten, wissen Sie genau, welches Ergebnis Sie für jeden Eingabewert erhalten. Und wenn Ihr Code nicht von einem verborgenen Zustand abhängt, ist er sehr einfach zu testen, und Sie werden sich nicht die Mühe machen, einen Komponententest zu schreiben. Wir alle wissen, dass unsere Software ohne Interaktion mit der Außenwelt nutzlos wäre, aber es gibt einen spürbaren Unterschied zwischen reinem Code (geschrieben mit reinen Funktionen / Methoden) mit Eingabe / Ausgabe nur an den Grenzen des Systems und einem System, in dem jede Methode vom internen Zustand abhängt. durch andere Methoden aktualisiert.
Noch einmal, ein kleines Umdenken des E / A-Ansatzes bietet alle Vorteile von FP, und das Testen wird so einfach, dass es endlich Spaß macht.
Deklarativ VS Imperativ
Wir haben die Sichtweise auf unseren Code bereits geändert - wir können sichereren (unveränderlichen) und testbaren (sauberen) Code schreiben. Jetzt ist es an der Zeit, ein wenig weiter zu gehen und den Ansatz zu ändern, um zu bestimmen, was unsere Software tun soll. Was unterscheidet OOP noch von AF? In einer funktionalen Welt definieren wir, was passieren soll, anstatt zu bestimmen, wie es passieren soll. Natürlich bleibt der Teil des Programms übrig, der diese bestimmte Operation ausführt, aber hier ist es wichtig, sich auf Ausdrücke anstatt auf Anweisungen zu konzentrieren. Und das können Sie in Ihrer bevorzugten OOP-Sprache tun.
Wenn Sie beispielsweise mit Dingen wie LINQ (aus C #) vertraut sind, kennen Sie die Vorteile von Abfrageausdrücken bereits, wenn Sie Ihren Code wie folgt lesen können: „Ja, hier nehme ich 10 Elemente aus der Sammlung, sortiere sie alphabetisch und verwende sie als Parameter für Folgendes Methode. " Sie haben wahrscheinlich Tausende von LINQ-ähnlichen Ausdrücken gelesen, ohne darüber nachdenken zu müssen, was tatsächlich hinter den Kulissen vor sich geht. Und das Wichtigste ist, sich auf das zu konzentrieren, was wirklich wichtig ist.
Zusammenfassung
Ich denke das reicht fürs Erste. Ich möchte FP nicht als Silberkugel verkaufen. Die Welt ist nicht nur schwarz und weiß. Die Wahrheit ist, dass FP für mich unglaublich schwierig ist. Fast so kompliziert wie richtiges OOP. Aber es ist definitiv einen Versuch wert. Aus meiner Sicht ist OOP vs FP im Großen und Ganzen die Art und Weise, wie ich über den Code und seine Struktur denke. Wie ich über Abhängigkeiten, Nebenwirkungen, die ganze Welt der E / A und Tests nachdenke. Zusammenfassend lässt sich sagen: „Ein funktionaler Ansatz hilft unabhängig von Sprache, Themenbereich und Plattform.“