Als ich sozusagen im Internet spazierte, bemerkte ich eine interessante Funktion. Alle an anderer Stelle diskutierten Programmierparadigmen werden von den Menschen recht ruhig wahrgenommen. Wenn sie zum Beispiel über prozedurale Programmierung sprechen, dann sprechen sie absolut ruhig darüber. Das gleiche gilt für die modulare Programmierung. Deklarative Programmierung - keine Stürme, Unruhen oder Holivarov. Die funktionale Programmierung ist dieselbe.
Und nur um die OOP herum die Stürme nicht beruhigen.
Einige quietschen entzückt vor ihm, andere bemängeln im Gegenteil, worauf das Licht basiert. Und um ehrlich zu sein, ist es für mich völlig unverständlich, warum die ganze Welt in OOP zusammengekommen ist.
Sie haben vielleicht gerade gedacht, dass ich eher ein Gegner als ein Verfechter von OOP bin. Dies ist absolut nicht der Fall (Sie können es jedoch aus dem Titel verstehen). Nein. Ich bin eher ein Gegner von Silberkugeln, Hype, der Inthronisierung einer bestimmten Methodik oder Person und allen Arten von Round Dance. Sie fahren nicht um Tänze herum, zum Beispiel um einen Schraubenschlüssel oder einen Rasenmäher. Und schreibe hoffentlich keine Veröffentlichungen, warum ein Bohrer oder Hammer saugt.
Aber heute wimmelt es im gesamten Internet von pompösen, hyperemotionalen, radikalen Artikeln über OOP - wenn einer sagt, dass OOP „zer gut“ ist und im Allgemeinen für alle gut gut, dann sendet der andere notwendigerweise, dass OOP dringend in den Müll geworfen werden muss (wenn nur er teilt nicht die Ansichten des ersten). Es gibt kein drittes.
Ich möchte nur das dritte Element einbringen. Es ist ruhig, ohne Hype und Missbrauch zu sagen, warum OOP nicht ein Elixier aller Krankheiten ist, sondern auch wie PP, AF oder PL das Recht hat zu existieren.
Also ein ruhiger Artikel zur Verteidigung der OOP. Darin werde ich versuchen, die Hauptargumente der Gegner der PLO zu berücksichtigen und ihr Versagen zu rechtfertigen.
1. Alles, was in OOP existiert, ist seit langem in anderen Paradigmen
Mit Ausnahme von Markup-Sprachen wie HTML, XML, CSS usw. sind fast alle Programmiersprachen vollständig. Turing spricht in einer Bauernsprache und ist eine vollständige Sprache - eine Sprache, in der Sie absolut jedes erdenkliche Programm schreiben können. Daraus folgt eine eher allgemeine These: Was in einer beliebigen gewählten Sprache ist, ist in allen anderen Sprachen. Gleiches gilt für Paradigmen. Alle Unterschiede in Sprachen (und Paradigmen) sind unterschiedliche Arten der Implementierung bestimmter Befehle, wobei einzelne lexikalische Merkmale nicht berücksichtigt werden.
Übrigens kann dieselbe These (alles, was in N, in M und in K und in R usw. ist) wie folgt formuliert werden: Der Hammer besteht bereits aus Eisen und Holz, warum brauchen wir auch eine Zange? Aber niemand wird es sagen.
2. OOP mischt Daten und Aktionen darauf. Das ist schlecht
Das Argument wird aus dem Finger gesaugt. Erstens, wo mischt OOP Daten und Funktionen? Zweitens stammt die Aussage, dass dies schlecht ist, auch aus einer Laterne, aus einem Fass, "ein richtiger Mann tut das nicht", und warum - wegen des Gladiolen. OOP modelliert in gewisser Weise die reale Welt, in der die Daten dem Objekt inhärent sind - niemand wird argumentieren, dass dem Stuhl die Farbe fehlt und er keine vier Beine hat. Und hier findet keine Vermischung von Daten und Operationen statt, das Objekt ist keine Funktion oder ein Operator.
Dies ist eine Abstraktion.3. Vererbung versklavt das Programm, erschwert Änderungen
Hier kann man etwas langsamer fahren. Vererbung bedeutet keineswegs den Bau von Kilometerbäumen, um die Entwicklung zu verlangsamen. Die Vererbung wurde erfunden, um gemeinsame Eigenschaften und Methoden in eine Oberklasse zu unterteilen, und dies muss mit Klassen erfolgen, die Objekte desselben Typs darstellen. Es ist ein Fehler, beispielsweise zwei Klassen zu erstellen, von denen eine der Erbe der anderen ist, da einer Oberklasse kein gemeinsamer Code zugewiesen wird, nur weil
nichts gemeinsam ist .
Wenn nicht beabsichtigt ist, die übergeordnete Klasse auf eine dritte Klasse zu erweitern, ist eine solche Vererbung einfach bedeutungslos. Wenn Sie ein Spirituosengeschäft einrichten, können die Klassen Bier, Wodka und Wein von der Klasse Alkohol übernommen werden. Sie müssen die Klasse Getränke jedoch überhaupt nicht erstellen, es sei denn, Sie möchten beispielsweise paraguayischen Tee verkaufen.
Es ist auch ein Fehler, Hierarchien zu erstellen, in denen Klassen nicht miteinander in Beziehung stehen. Nun, warum, sagen Sie mir, einen Turm zu bauen, in dem die Klassen Fly und Cutlet von der Oberklasse Cheese geerbt werden, die wiederum von der Superklasse Friday geerbt wird ?! Dies ist jedoch kein Defekt von OOP mehr, sondern die krummen Hände desjenigen, der es komponiert.
4. Kapselung macht keinen Sinn
Hier stimme ich teilweise zu. Aus Sicht des Programms hat die Kapselung wirklich keinen Einfluss auf irgendetwas. Wenn ich die Variable mit private schließe, kann ich sie trotzdem öffnen, indem ich einfach private entferne und dort alles ändere, was mir gefällt.
Dies gilt aber nur technisch. Die OOP-Philosophie lautet, dass eine ordnungsgemäß organisierte und gekapselte Klasse als Black Box angesehen werden kann. Stellen Sie sich eine Box vor, auf deren einer Seite sich verschiedene Schaltflächen, Steckplätze für die Datenversorgung und auf der anderen Seite ein Ausgabeschlitz befinden, der Informationen zurückgibt. Nehmen Sie zum Beispiel einen Stapel. Stellen Sie sich eine Box vor, auf deren einer Seite sich ein Steckplatz zum Einfügen von Daten und ein Druckknopf daneben befinden. Auf der Rückseite befindet sich der Pop-Button. Sie senden eine Notiz mit der Nummer 8 und drücken den Druckknopf. Dann geben Sie ein weiteres Stück Papier und drücken zum zweiten Mal auf Drücken. Und so N-mal und dann Pop drücken. Aus der Schublade fliegt ein Stück Papier mit der Nummer 76 (oder einem anderen, im Allgemeinen dem von Ihnen eingereichten). Benötigen Sie eine andere Nummer? Drücken Sie ein zweites Mal Pop. Und so weiter bis zur
Verschwörung der
Karotte, bis die Schachtel leer ist. Und wenn Sie weiter auf Pop drücken, erobert der Mechanismus aus der Box: Der Stapel ist leer! Genau so sieht das Objekt aus.
Nachdem Sie die Klasse erstellt und konfiguriert haben, ist sie für Sie bereits violett, wie sie dort funktioniert. Sie funktioniert nur korrekt, aber Sie müssen sich nicht mehr wünschen. Wenn Sie all diese Strukturen einkapseln, behalten Sie nicht alles im Gedächtnis. Sie (viele Boxen) sprechen einfach so miteinander, wie Sie es eingerichtet haben.
Kapselung ist eine Art Krücke, die die Hunderte von Säulen Ihres Programms unterstützt, während Sie einhundertundein bauen. In großen Projekten (nämlich um sie zu erstellen, wurde OOP erfunden) ohne dies leider nichts.
Obwohl es hier kaum "leider" allgemein angemessen ist.
5. In der realen Welt gibt es keine Beziehungshierarchien, sondern überall nur Einschlusshierarchien
Ist es wirklich so? Aber niemand stört sich daran, zum Beispiel eine Hierarchie zu schaffen, in der alle Flüsse der Welt (Kongo, Seine, Themse, Amazonas, Kolyma usw.) Objekte eines allumfassenden „Flusses“ sind, der inhärente Eigenschaften hat (zum Beispiel aus Wasser besteht) und Aktionen (zum Beispiel Flüsse), und bereits wird es vom „Teich“ geerbt, der ebenfalls aus Wasser besteht, und vom „Teich“ können Sie auch den „See“ erben, dessen Objekte separate Seen sind (Baikal, Kaspisches Meer, Titicaca usw.). .d.). Das Schema ist ziemlich grob. Beziehungshierarchien sind aber auch eine
Abstraktion . Etwas a la platonische Idee, wenn Sie wollen. In der realen Welt sind sie nicht da, sie existieren nur im Geist, dies ist eine Verallgemeinerung und nichts weiter. Aber genau so denkt ein Mensch sehr oft. Wir können "Socke" sagen, ohne anzugeben, welche Farbe es hat, aus welchem Material es gewebt ist usw. Aber gibt es diese "Socke" wirklich?
Trotzdem sollte es uns nicht peinlich sein, dass es kein „Objekt“ oder „Socke“ gibt.
6. Die OOP-Methodik ist anfangs fehlerhaft
Ein absolut unbegründetes Argument. OOP wurde erstellt, um eine Art virtuelle Welt zu simulieren, die aus Objekten wie unserer Welt besteht. Zum Beispiel: Eine Person ist ein Objekt aus der realen Welt. Er kann laufen, rennen, essen,
scheißen , Fußball spielen, Fußball schauen, aber leider kann ich hier nicht alles auflisten, und ehrlich gesagt wäre es widerlich, alles aufzulisten. Dieselbe Person hat die folgenden Eigenschaften: Vorhandensein / Nichtvorhandensein von Haaren, Haarfarbe, falls vorhanden, Augenfarbe, Hautfarbe, Anzahl der Finger usw. Wenn Sie alle Felder und Methoden korrekt konstruieren, wie oben beschrieben, kann das Programmobjekt bestimmte Eigenschaften eines realen Objekts modellieren. Eine Person denkt in solchen Kategorien sehr gut - deshalb ist OOP weit verbreitet. Dies ist beim Schreiben großer Projekte sehr hilfreich, da es die Modularität einführt und es Ihnen ermöglicht, ein Softwarepaket in separate Komponenten aufzuteilen, die miteinander interagieren.
7. Aber selbst Millionen von Fliegen werden uns nicht davon überzeugen, dass Gülle köstlich ist.
Das beliebteste Argument gegen OOP. Die Massen sind meistens dumm (aber ich glaube nicht, dass dies auch für Programmierer gilt), laufen um die "modischen Klamotten" herum und bewundern sie.
Aber denken Sie darüber nach, und wenn nicht PLO, sondern LP, das Podest betreten hatte? Glaubst du, es wäre anders? Nichts dergleichen! Es hätte Fans und böswillige Gegner gegeben, und sie hätten die PLO als Instrument angesehen (dazu nenne ich das eigentlich) und nicht als Pille, die von Gott selbst geschaffen und daher unersetzlich ist.
Warum ist dieser Artikel zur Verteidigung der PLO?
Das ganze moderne Gerede über Programmierparadigmen, wie ich es sehe, läuft auf zwei diametrale Prämissen hinaus: Wir werden OOP verlassen und den Rest wegwerfen oder OOP rauswerfen und ... nun, Sie verstehen mich.
Ich möchte nicht, dass ein völlig geeignetes Paradigma als würdiger Dump angesehen wird, aber ich möchte keinen Round Dance, aber ich habe alles andere vergessen. Ich denke, dass der zweite einfacher ist, aber dieser Artikel richtet sich gegen den ersten.
Wenn Sie OOP nicht mögen
An wen - OOP, an wen - FP, an wen - PP. Und für jemanden ist der Schweineknorpel im Allgemeinen vielleicht am süßesten. Wenn Sie keine Katzen mögen, wissen Sie wahrscheinlich nicht, wie man sie kocht.