Der Beitrag enthält eine gewisse Menge an Scherzen, das Gesundheitsministerium bittet einen unvorbereiteten Leser überzeugend, nicht zu lesen.Artikel zum Thema "AF ist besser" oder "OOP ist besser" ähneln einer Debatte darüber, was für ein Mittagessen, eine Gabel oder einen Löffel am besten ist. Traditionell begannen die Junes mit einem Löffel, aber jemand, der sehr maßgeblich war, sagte mir einmal, dass er nur Fleisch isst und eine Gabel benutzt, also ist eine neue Mode entstanden - mit einer Gabel essen. Sie essen Haferbrei und Suppen und schaffen es sogar, Smoothies zu lecken. Das Internet ist übersät mit Artikeln, wie gut wir sind, dass wir gelernt haben, einen Smoothie mit einer Gabel zu essen und alle Rechen zu überwinden. Dies ist sowohl lustig als auch traurig. Einerseits verschafft es erfahrenen Leuten einen Wettbewerbsvorteil, die super Ergebnisse zeigen, wenn sie diesen Hype einfach ignorieren. Andererseits müssen sie Kollegen und Mitarbeiter neu schulen und den durch den Wind verursachten Müll von ihren Köpfen entfernen. In diesem Artikel werde ich versuchen, meine Vision zu erzählen, die nicht behauptet, absolute Wahrheit zu sein, aber in der Praxis sehr gut funktioniert
Wie in der Wissenschaft üblich, beginnen wir mit Definitionen. Die klassische Definition von OOP beinhaltet das Befolgen der Prinzipien von Vererbung, Einkapselung und Polymorphismus. Aber wenn wir keine dieser Komponenten haben, wird es dann OOP sein? Und wenn nicht, was wird es sein?
Während der langweilige Teil des Publikums über dieser Unpraktik schwebte und uns keine Frage stellte , erinnern wir uns daran, was vor der PLO passiert ist . Und vor ihm war prozedurale Programmierung. Die Hauptidee von OOP war zu dieser Zeit die
Verbindung von Daten und Funktionen für deren Verarbeitung . Die Idee ist einfach, aber ziemlich revolutionär, es ist schwer vorstellbar, wie viel, aber dazu später mehr.
Die funktionale Programmierung betrachtet das
Programm in einer freien Interpretation
als eine mathematische Formel . Formeln sind gut formalisiert und geben mit derselben Eingabe dieselbe Ausgabe zurück. Das gesamte Programm besteht aus Routinen, die denselben Prinzipien folgen. Wie unterscheidet sich dies von der gleichen prozeduralen Programmierung? FP verwendet aktiv
reine Funktionen , idealerweise sollte das gesamte Programm eine reine Funktion sein. Reine Funktionen
haben keine Nebenwirkungen , sie können leicht auswendig gelernt, leicht getestet usw. werden. Wir können sagen, dass in reinen Funktionen die Hauptidee und der Vorteil von FP ist.
Und jetzt zwei Fragen:
- Können wir reine Funktionen in OOP verwenden?
- Können wir Funktionen an Daten im FP binden?
Die Antwort auf beide lautet ja. Statische Klassenmethoden können rein sein, selbst Instanzmethoden können als sauber betrachtet werden, wenn sie keine Nebenwirkungen verursachen, und wir betrachten die Eigenschaften der Klasseninstanz als Parameter. Die Grenzen der klassischen Definitionen sind aufgeblasen und einige mögen anderer Meinung sein, aber in der Praxis funktioniert es einfach. Und solche Methoden werden nicht schlechter formalisiert und getestet als klassische reine Funktionen, die nach allen Kanonen geschrieben wurden. Das Binden von Methoden an Daten ist etwas komplizierter, die verwendete Sprache und Bibliotheken unterliegen Einschränkungen. Nehmen wir an, in JavaScript geschieht dies elementar, wobei Haskell und Erlang nicht sicher sind. Das Interessanteste ist nun, was es gibt und warum die OOP bereits vor 20 bis 30 Jahren einen solchen Hype ausgelöst hat. Wenn Sie ein kleines Programm schreiben, können Sie schreiben, wie Sie möchten, außer Ihrem Sinn für Schönheit hat dies keine Auswirkungen. Wenn Sie ein wirklich großes Programm erstellen, tritt ein Problem der Komplexität auf. Nicht von rechnerischer Komplexität, wir glauben, dass wir hier alles gut machen, sondern von wahrgenommener Komplexität. Angenommen, Sie haben 50.000 Codezeilen, und alle sind nützlich. Wie kann man sie organisieren, um nicht verrückt zu werden (oder um 11 Nächte nicht von der Arbeit zu gehen)? Wir können die Anzahl der Operationen nicht reduzieren, aber wir können die Anzahl der Verbindungen zwischen ihnen reduzieren (die Kapselung hilft uns dabei). Wir verstecken die komplexe Implementierung hinter einer einfachen Schnittstelle und arbeiten weiterhin nur mit der Schnittstelle. Zum Beispiel ist das Internet eine schrecklich komplizierte Sache, aber die meisten Entwickler verfügen über ausreichende Kenntnisse des HTTP-Protokolls, um ihre Arbeit zu erledigen
und das Netzwerk, die physischen und andere Ebenen den Systemadministratoren zu überlassen . Je schwächer die Konnektivität unserer Module ist, desto
geringer ist die Komplexität in der Phase ihrer Integration untereinander. Je weniger ein Modul über das andere weiß, desto weniger sind sie verbunden. Das Binden von Methoden an Daten innerhalb des Moduls hilft uns, dieses Wissen von den Verbrauchern des Moduls loszuwerden. Dies ist der pragmatische Hauptvorteil von OOP. Über was? Oben Ansatz ohne Daten- und Methodenbindung. FP sagt, wie wir herausgefunden haben, nichts darüber aus. Sie können Klassen als Argumente an reine Funktionen übergeben oder reine Funktionen als Methoden einer Klasse verwenden. Sie widersprechen sich nicht, sondern ergänzen sie nur.
Wo funktioniert in der Praxis hauptsächlich ein Ansatz und wo ist der andere hauptsächlich? Wenn ich ein
Backend auf NodeJS schreibe, entpuppt es sich irgendwie als eigenständiges
Funktionsparadigma . Warum? Weil die Anfrage an den Server von Natur aus eine Funktion mit einer festen Ein- und Ausgabe ist. Der funktionale Ansatz hängt ganz natürlich von Serveranforderungen ab und der Code ist kompakter und flexibler. Wenn ich ein
Frontend für den Browser erstelle, funktioniert
OOP normalerweise besser, da neben der Eingabe und Ausgabe auch eine
Reihe von Benutzerereignissen sowie Programmereignisse wie Anfang und Ende von Animationen, Serveranforderungen usw. vorhanden sind. Der funktionale Ansatz hat funktioniert Wenn nur eine statische Seite ohne Interaktivität gezeichnet werden soll, leidet bei Verwendung des FP im Frontend entweder die interaktive oder die Entwicklungszeit (nach unseren Messungen alle drei Male). Warum?
Jedes Programmierparadigma basiert auf einem bestimmten Realitätsmodell, und ein Modell ist immer eine Vereinfachung. In FP legt das Modell der Welt mehr Einschränkungen auf, sodass es einfacher zu formalisieren ist. Aus dem gleichen Grund werden mehr Krücken benötigt, wenn es für die Bedingungen des Problems irrelevant wird. Zum Beispiel lösten Front-End-FIs das Problem der Benutzereingabe, indem sie eine Reihe von Ereignissen (Aktionen, Redux Hi) erstellten. Dies ist jedoch eine irrelevante Abstraktion, die zusätzlich zu ihren Auswirkungen auf die Leistung die Entwicklungszeit erheblich verlängert. Mit diesem Ansatz können Sie eine Aufgabenliste erstellen, aber bei wirklich großen Projekten müssen Sie Steine mit der Stirn brechen und dann siegreiche Artikel für dieselben unglücklichen schreiben. Zum Vergleich: Als wir das Exchange-Terminal (natürlich auf Vanilla JS) mit Canvas, SVG geschrieben und mehrmals pro Sekunde über Websockets aktualisiert haben, haben wir in einigen häufig aktualisierten Komponenten Divs nicht gelöscht, sondern wiederverwendet, da ihre Neuerstellung relativ teuer ist Bedienung im Browser (und dies ist wichtig, wenn Sie eine
wirklich große Anwendung haben ). Wenn Sie am Frontend programmieren, haben Sie nicht einmal einen solchen Gedanken, da Sie sich bereits mit Unveränderlichkeit abgefunden haben (dies ist übrigens eine wunderbare Sache für die Arbeit mit Multithreading, was in JS
nicht der Fall ist ), sodass jede Aktion jeden Reduzierer durchläuft und anderer Müll. Andererseits stellt sich im Backend häufig heraus, dass auf Klassen überhaupt verzichtet werden muss, da Sie dort nur die Kosten für deren Erstellung vermeiden können, da die Bedingungen der Aufgaben für das FP-Modell sehr relevant sind. Aber zum größten Teil haben Java- und PHP-Entwickler es nicht eilig, das FP zu studieren. Front-End-Anbieter stehen an vorderster Front und brauchen es wirklich am wenigsten. Als Übung für den Verstand - natürlich ist es interessant, dass nur die Programme erhalten werden, aber ... und jemand anderes sie verwendet. Trotz der Tatsache, dass das Frontend ein relativ junger Teil der IT ist und seine Aufgaben dort seit mehreren Generationen ungelöst sind. Was ist anscheinend keine Übung für den Geist?