Es ist Zeit, von OOP wegzukommen
OOP gilt als der größte Diamant in der Krone der Informatik. Der beste Weg, um Ihren Code zu organisieren. Die Lösung für alle Probleme. Der einzig sichere Weg, um unsere Programme zu schreiben. Der Gott der Programmierung hat uns von oben geschickt ... Nur hier ist der OOP-Programmierer gezwungen, eine Reihe von Abstraktionen aller Art zu harken, alle gemeinsam genutzten Objekte zu verfolgen, sich an Tonnen von "Programmiermustern" zu erinnern - und ihre Zeit und Energie für all dies aufzuwenden, anstatt das Problem selbst zu lösen.
Viele haben OOP lange kritisiert, und es gibt viele hoch angesehene Programmierer unter diesen Kritikern. Und sogar Alan Kay - der Erfinder von OOP ist in ihren Reihen!
Das Hauptziel eines jeden Entwicklers ist es, zuverlässigen Code zu schreiben. Wenn der Code fehlerhaft ist und nicht wie beabsichtigt funktioniert, ist nichts anderes wichtig. Was ist der beste Weg, um zuverlässigen Code zu schreiben? Halten Sie den Code einfach. Einfachheit ist das Gegenteil von Komplexität . Daraus folgt, dass das Hauptziel des Entwicklers darin besteht, die Komplexität des Codes zu reduzieren.
Haftungsausschluss:
Ich bin kein OOP-Fan, daher ist es keine Überraschung, dass dieser Artikel vielen voreingenommen erscheint. Ich werde jedoch Argumente zur Verteidigung meiner Position vorbringen.
Ich verstehe auch sehr gut, dass Kritik an OOP für viele sehr schmerzhaft ist. So viele Leser werden sich persönlich beleidigt fühlen. Ich möchte jedoch angeben, was ich für richtig halte. Denn mein Ziel ist es nicht zu beleidigen, sondern auf die Probleme hinzuweisen, die OOP hat. Ich bin nicht zu kritisieren Alan Kay
‚s OOP . Er ist im Allgemeinen ein Genie. Ich persönlich wünschte, OOP wäre genau das, was Alan Kay beabsichtigt hatte. Was ich kritisiere, ist OOP in einer C # - oder Java-Implementierung.
Das Problem ist, dass OOP seit langem als Standard für die Organisation von Software-Code gilt. Und so viele Leute denken, einschließlich derer, die ernsthafte Positionen in der Softwareindustrie innehaben, weshalb andere Programmieransätze in den meisten Unternehmen nicht einmal in Betracht gezogen werden.
Ich musste viele Schwierigkeiten überwinden, als ich in OOP-Sprachen schrieb. Und ich habe mich immer gefragt, warum diese Schwierigkeiten entstanden sind. Vielleicht war ich nicht zu gut? Vielleicht musste ich noch ein paar Dutzend "Programmiermuster" lernen? Am Ende hatte ich einfach nicht mehr die Kraft für all das.
Dieser Artikel erzählt Ihnen die zehn Jahre lange Reise, die ich von OOP zur funktionalen Programmierung unternommen habe. Seitdem erinnere ich mich nicht mehr an einen Fall, in dem ich auf ein Projekt gestoßen bin, für das OOP am besten geeignet wäre. Darüber hinaus scheiterten Projekte, bei denen OOP verwendet wurde, unter der Komplexität des Codes - irgendwann war es unmöglich, sie weiterzuentwickeln und weiterzuentwickeln.
TLDR
"Objektorientierte Programme sind die Alternative zu den richtigen Programmen."
Edsger W. Dijkstra, Pionier der Informatik
Der Zweck von OOP war einer - die Komplexität des Verfahrenscodes zu bewältigen. Mit anderen Worten, OOP wurde entwickelt, um die Code-Organisation zu verbessern. Seitdem gibt es jedoch keine Hinweise darauf, dass OOP besser ist als die alte prozedurale Programmierung.
Die harte Wahrheit ist, dass OOP nicht das getan hat, wofür es entwickelt wurde. Auf dem Papier sah alles gut aus - wir hatten strenge Hierarchien von Tieren, Hunden, Menschen ... (Und natürlich Formen: Rechtecke, Quadrate und Kreise - wohin können wir ohne sie gehen!) Aber als die Komplexität des Anwendungscodes zunahm, half OOP nicht, ihn zu reduzieren , aber im Gegenteil, mit Tonnen von notwendigen "Programmiermustern" und der Schwierigkeit für den Programmierer, zu verfolgen, wo und wie sich die Werte von Variablen ändern. OOP machte viele häufig verwendete Verfahren wie Refactoring und Testen unnötig komplex.
Viele Leute stimmen mir nicht zu, aber Tatsache ist, dass das Design von OOP in C # oder Java nicht wissenschaftlich durchdacht war, sondern nicht das Ergebnis ernsthafter wissenschaftlicher Forschung. Im Gegensatz zur funktionalen Programmierung beispielsweise in Haskell, wo die Lambda-Rechnung eine solide theoretische Grundlage darstellt. OOP basiert nicht auf so etwas.
In kleinen Projekten schneidet OOP recht gut ab. Aber was passiert, wenn das Projekt wächst? OOP ist eine Zeitbombe, die unweigerlich explodiert, wenn der Projektcode eine bestimmte Größe erreicht. Projekte beginnen zu verzögern, Fristen scheitern, Entwicklern geht die Energie aus und das Hinzufügen neuer Funktionen wird fast unmöglich. Am Ende sind Unternehmen gezwungen, solchen Code als "veraltet" zu markieren und Entwickler zum Umschreiben zu zwingen.
OOP passt nicht sehr gut zu der Art und Weise, wie unser Gehirn denkt. Wir sind es gewohnt, uns auf Action zu konzentrieren: spazieren gehen, mit einem Freund reden, Pizza essen. Unser Gehirn hat sich dahingehend entwickelt, "etwas zu tun" und nicht eine komplexe Hierarchie abstrakter Objekte aufzubauen.
OOP-Code ist nicht deterministisch (im Gegensatz zur funktionalen Programmierung): Wir können nicht sicher sein, dass wir mit denselben Eingabedaten jedes Mal dasselbe Ergebnis erhalten. Dies macht es sehr schwierig zu verstehen, wie das Programm funktioniert. Hier ist ein einfaches Beispiel: Vergleiche 2 + 2 und Taschenrechner. Füge (2, 2) hinzu . Der letzte Ausdruck sollte theoretisch immer 4 zurückgeben, kann aber aufgrund der Abhängigkeiten des Calculator- Objekts 5, 3 oder sogar 1004 zurückgeben kann sein Verhalten auf unvorhersehbare Weise ändern.