Eine Frage an die OOP-Experten. - Seite 10

 
A100:

Und das bin ich auch - nach und nach... und das volle Verständnis kommt erst nach 4-5 Jahren (und das ist normal für einen normalen Menschen)

Meiner Meinung nach ist "volles Verständnis" nicht erforderlich. Die Hauptsache ist, "das Wesentliche zu begreifen". 1995 habe ich mich mit der OOP-Methodologie vertraut gemacht.

Ich hatte bereits einige Erfahrung mit "regulärem C" im Geiste von K&R (Oldfags müssen sich erinnern), außerdem habe ich oft Assembler-Funktionen benutzt. Anfangs stand ich OOP-Ideen eher skeptisch gegenüber, nicht einmal so sehr, weil der Programmierer einige zusätzliche Aktionen durchführen musste, sondern wegen des reinen CPU-"Overheads". Aber ich war bald von der Nützlichkeit dieser Technologie überzeugt, und dieKlasse CString war der entscheidende "Schalter" in meinem Kopf.

Darüber hinaus war die Arbeit mit Zeichenketten viel einfacher: Damals schrieben wir einen Datenpacker, und mein Part war die Analyse des Eingabetextes. Daher erschien es sehr bequem, eine Hierarchie verschiedener Strings auf der Grundlage der Klasse CString zu erstellen, was für unseren Packer wichtige Unterschiede mit sich brachte.

Besonders gut gefiel mir, dass sich nach der Erstellung des Datenpackers die Aufgabe stellte, ihn für Strings zu verwenden, die eine Menge digitaler Informationen enthielten, für die der Packer ursprünglich nicht konzipiert war. Der Packer hat solche Daten zwar gepackt, aber er hat es getan, indem er das Eingabealphabet nur als Zeichen betrachtete, aber wissend, dass die Zeichenkette aus einigen Wörtern und Ziffern besteht - das hat den Packer ohne Geschwindigkeitsverlust erheblich verbessert. Also wurde eine Klasse geschrieben, die solche Zeichenketten mit Ziffern repräsentiert (und auch ein spezieller Kompressor für Ziffern), alles wurde zu den bestehenden Klassen hinzugefügt und der Packer begann mit den neuen Daten zu arbeiten, obwohl diese Funktionalität ursprünglich nicht erwartet wurde.

Damals habe ich das Potenzial von OOP zur Änderung und Pflege von Code wirklich zu schätzen gelernt. Natürlich entsteht ein gewisser CPU-Overhead, der jedoch durch die geringere Arbeit der Programmierer mehr als kompensiert wird.

Deshalb empfehle ich jedem, der mit dem Erlernen von OOP beginnt, mit solchen Aufgaben zu beginnen, bei denen die Vorteile von OOP gut und deutlich sichtbar sind. Das heißt, mit den Aufgaben der Verarbeitung verschiedener Objekte in Listen, die Instanzen von Klassen mit einem gemeinsamen Vorfahren darstellen würden.
 
Igor Makanu:

Sehen Sie, ich habe diesen Kanal abonniert, im Allgemeinen habe ich eine positive Meinung über den Autor, und es gibt sogar eine Wiederholung des Themas Ihres Videos, mit dem der Streit begann:

Ich stimme fast vollständig mit allen Gedanken in dem Video überein. Es gibt ein paar kleinere, nicht einmal Einwände, sondern Klarstellungen (zum Beispiel halte ich NULL für einen sehr nützlichen Zeiger, der einen Fehler anzeigt, wir sollten nur bedenken, dass die Funktion diesen Null-Zeiger zurückgeben kann, und, klar, das Video sagt richtig - es kann nicht als Objekt behandelt werden).

Und alles andere über Ungenauigkeiten, Reihenfolge der Entwicklung, Getter-Setzer und der gleichen NULL ist richtig.

Großes Lob an den Autor.

 

Es ist seltsam, dass ich, der ich ein philosophischer und abstrakter Mensch bin, so verzweifelt die von den Profis geliebte Herangehensweise an die Programmierung ablehnen möchte. Die OOP, die eigentlich praktisch sein sollte, ist mit Entitäten überwuchert und für ihre Aufgaben überflüssig geworden. Die "Redundanz" der Werkzeuge erschwert die Lösung ebenso wie die Knappheit. Und diese Redundanz ist zweifelsohne eine Folge des Marketings. Man sollte meinen, dass eine minimale OOP ausreicht, um alle Probleme im Bereich der Informatik zu lösen. Genauso wie alles mit einfachen Funktionen und ordentlicher Speicherverwaltung erstellt werden kann. Auf der ersten Ebene habe ich OOP sofort übernommen. Dann bemerkte ich, dass einige Wesenheiten die Notwendigkeit ihrer Existenz nicht rechtfertigen konnten und ihr eigenes, von den Aufgaben abstrahiertes Leben innerhalb des wachsenden Konzepts führten. Ja, sie sind in Lösungen eingebettet, aber sie schmarotzen an der Intelligenz der Entwickler. Sie verlangsamen den Arbeitsprozess und verringern seine Effizienz. Sie behindern den Arbeitsablauf durch Verschleierung, Syntax, Regeln... Das ist es, was mir an dieser Optionalität innerhalb der Lösung nicht gefällt.

Ich werde also das minimalste OOP verwenden. Diejenige, die vor der Vermarktung erstellt wurde.

 
Реter Konow:

Es ist seltsam, dass ich, der ich ein philosophischer und abstrakter Mensch bin, so verzweifelt die von den Profis geliebte Herangehensweise an die Programmierung ablehnen möchte. Die OOP, die eigentlich praktisch sein sollte, ist mit Entitäten überwuchert und für ihre Aufgaben überflüssig geworden. Die "Redundanz" der Werkzeuge erschwert die Lösung ebenso wie die Knappheit. Und diese Redundanz ist zweifelsohne eine Folge des Marketings. Man sollte meinen, dass eine minimale OOP ausreicht, um alle Probleme im Bereich der Informatik zu lösen. Genauso wie alles mit einfachen Funktionen und ordentlicher Speicherverwaltung erstellt werden kann. Auf der ersten Ebene habe ich OOP sofort übernommen. Dann bemerkte ich, dass einige Wesenheiten die Notwendigkeit ihrer Existenz nicht rechtfertigen konnten und ihr eigenes, von den Aufgaben abstrahiertes Leben innerhalb des wachsenden Konzepts führten. Ja, sie sind in Lösungen eingebettet, aber sie schmarotzen an der Intelligenz der Entwickler. Sie verlangsamen den Arbeitsprozess und verringern seine Effizienz. Sie behindern den Arbeitsablauf durch Verschleierung, Syntax, Regeln... Das ist es, was mir an dieser Optionalität innerhalb der Lösung nicht gefällt.

Ich werde also das minimalste OOP verwenden. Diejenige, die vor der Vermarktung erstellt wurde.

Ja. Sie erstellen zum Beispiel eine Klasse, die mit einer Datei arbeitet. Man fängt an, es zu benutzen und bekommt Bugs. Sie schließen einen Teil des Codes und versuchen, im anderen Teil etwas damit zu tun. Es gibt zwei Ansätze. Die erste besteht darin, dass man versucht, sich immer daran zu erinnern, wo etwas hergestellt wurde, und selbst bei einem einzigen Entwickler kann das nicht sehr gut sein. Die zweite - vor der Aktion der Überprüfung Operationen zu tun. Okay, der nächste Fehler: in den Überprüfungsvorgängen, die über den gesamten Code verstreut sind, gibt es hier und da Tippfehler, falsche Vorzeichen, an einer Stelle korrigiert, an einer anderen vergessen, usw. Das Ergebnis ist, dass Sie von einer so geliebten Effizienz des Codes zu einer trivialen und einfachen Sache übergegangen sind: Jede Read/Write-Methode und dergleichen enthält einen Aufruf einer Prüfmethode, die es Ihnen ermöglicht, sie rückgängig zu machen, wenn Sie sie aufrufen, was Sie fast nie verwenden werden. Und dann stellt man fest, dass dies eine gute Sache ist, denn moderne Hardware erlaubt es, bei 98 % der gelösten Aufgaben keine Taktzyklen und keinen Speicherverbrauch zu zählen.

 
Vladimir Simakov:

Ja. Sie erstellen zum Beispiel eine Klasse, die mit einer Datei arbeitet. Man fängt an, es zu benutzen und bekommt Bugs. Sie schließen einen Teil des Codes und versuchen, im anderen Teil etwas damit zu tun. Es gibt zwei Ansätze. Erstens muss man versuchen, sich immer daran zu erinnern, wo etwas hergestellt wurde, und selbst bei einem einzigen Entwickler kann es passieren, dass man das nicht schafft.

Peter ist gut darin.

Das ist das Problem - Peter ist es gewohnt, eine riesige Tabelle mit allen Variablen zu verwenden, die immer im gesamten Programm verfügbar ist und aus der er sich jederzeit das nimmt, was er braucht. Für den Titanen des Auswendiglernens ist das ziemlich praktisch.

In der OOP ist die Kapselung ein Archivierungsmerkmal, das nur dazu dient, sicherzustellen, dass der Benutzer irgendwo im Code nur auf die Variablen zugreifen kann, die er braucht, und nicht auf andere Variablen. Aber für Peter ist das ein Minuspunkt, denn er weiß bereits, wo, was und wie er es benutzt hat, und er möchte jederzeit auf jede Variable in jedem Teil des Programms zugreifen können. Er mag meinen Ansatz nicht, bei dem man, um auf eine Variable zuzugreifen, zuerst einen Zeiger auf die Schnittstelle erhalten muss, und von der Schnittstelle muss man die Funktion erhalten, und erst dann gibt sie den benötigten Wert zurück. Bei jedem dieser Schritte können Sie auf eine Zugangsbeschränkung stoßen. Ich halte das für eine gute Sache, denn wenn es eine Einschränkung gibt - und das hat seinen Grund -, dann bedeutet das, dass ich einige wichtige Details nicht bedacht habe. Und für Peter ist das ein Hindernis, weil er immer alles in Betracht zieht.

 
Vladimir Simakov:

Ja, Sie haben eine Klasse erstellt, die z. B. eine Datei behandelt. Sie fangen an, es zu benutzen und bekommen Fehler. Sie schließen einen Teil des Codes und versuchen, im anderen Teil etwas damit zu tun. Es gibt zwei Ansätze. Die erste besteht darin, dass man versucht, sich immer daran zu erinnern, wo etwas hergestellt wurde, und selbst bei einem einzigen Entwickler kann das nicht sehr gut sein. Die zweite - vor der Aktion der Überprüfung Operationen zu tun. Okay, der nächste Fehler: in den Überprüfungsvorgängen, die über den gesamten Code verstreut sind, gibt es hier und da Tippfehler, falsche Vorzeichen, an einer Stelle korrigiert, an einer anderen vergessen, usw. Das Ergebnis ist, dass Sie von einer so geliebten Effizienz des Codes zu einer trivialen und einfachen Sache übergegangen sind: jede Read/Write-Methode und so weiter hat einen Aufruf zu einer Prüfmethode mit einer Option, diesen Aufruf rückgängig zu machen, die Sie fast nie verwenden werden. Und dann stellt man fest, dass dies eine gute Sache ist, denn moderne Hardware erlaubt es, bei 98 % der gelösten Aufgaben keine Taktzyklen und keinen Speicherverbrauch zu zählen.

Stellen wir uns einmal die umgekehrte Situation vor. Nun, Sie haben keine Wanzen. Überhaupt nicht und fast nie, denn Sie erinnern sich an ALLES und berücksichtigen ALLES! Würden SieOOP nur aufgrund Ihrer "beruflichen Verpflichtung"verwenden? Das glaube ich nicht. Was würde Sie dann interessieren? - Nur die Effizienz Ihrer Codes. Sie werden versuchen, den gesamten Overhead zu entfernen, damit der Code so schnell wie möglich funktioniert. Sie werden auch versuchen, Ihren Code so zu erstellen, dass er sich schnell entwickelt.

Wenn man mir von Fehlern erzählt, die hier und da auftreten, verstehe ich sie, aber wenn sie mit der Verwendung oder Nichtverwendung von OOP zusammenhängen, bin ich nicht einverstanden. Die Anzahl der Bugs hängt von der Kenntnis und dem Verständnis des eigenen Codes ab. Derjenige, der den Code schreibt, kennt ihn besser als derjenige, der ihn einsteckt. Derjenige, der sie schreibt, hat immer weniger Bugs. Wie Sie wissen, fördert OOP die Übertragbarkeit von Code, dessen Kehrseite ein schlechtes Verständnis durch andere Programmierer ist. Das ist die Quelle von Fehlern.

Ich schreibe alles selbst, und ich finde Fehler in Blöcken von 2000 Zeilen ohne Profiler und Checker-Funktionen. Ganz einfach, ich kenne meinen Code. Das beste Mittel gegen Ungeziefer.))

 
Georgiy Merts:

Für Peter funktioniert es.

Das ist das Problem - Peter ist es gewohnt, eine riesige Tabelle mit allen Variablen zu benutzen, die immer im gesamten Programm zur Verfügung steht und aus der er jederzeit das entnehmen kann, was er braucht. Für den Titanen des Auswendiglernens ist das ziemlich praktisch.

Die Kapselung in der OOP ist eine Archivierungsfunktion, die genau dazu dient, dass der Benutzer nur auf die Variablen zugreifen kann, die er an irgendeiner Stelle des Codes benötigt, und nicht mehr. Aber für Peter ist das ein Minuspunkt, denn er weiß bereits, wo, was und wie er es benutzt hat, und er möchte jederzeit auf jede Variable in jedem Teil des Programms zugreifen können. Er mag meinen Ansatz nicht, bei dem man, um auf eine Variable zuzugreifen, zuerst einen Zeiger auf die Schnittstelle erhalten muss, und von der Schnittstelle muss man die Funktion erhalten, und erst dann gibt sie den benötigten Wert zurück. Bei jedem dieser Schritte kann eine Zugangsbeschränkung auftreten. Ich halte das für eine gute Sache, denn wenn es eine Einschränkung gibt - und das hat seinen Grund -, dann bedeutet das, dass ich einige wichtige Details nicht bedacht habe. Und für Peter ist das ein Hindernis, weil er immer alles in Betracht zieht.

George, es geht nicht nur um das Gedächtnis. Ich habe mir eine bequeme Entwicklungsumgebung geschaffen, in der ich meine Muttersprache und auch Englisch verwenden kann. Ein zweisprachiger Code ist viel besser zu merken als ein einsprachiger. Vor allem, wenn man nicht an Standardwörter gebunden ist und Variablen mit beliebigen Namen benennen kann. Bewährt. Ich habe die Professionalität des Programmierens einfach ignoriert und angefangen zu schreiben, was ich wollte. Das Ergebnis war, dass ich mich schnell in meinem Code zurechtfand und ihn leicht lesen, abrufen und weiterentwickeln konnte. Außerdem wissen Sie...

ZS: Lassen Sie sie nicht denken, dass ich Sie dazu auffordere, sich einen Dreck um Professionalität zu scheren. Auf keinen Fall. Ich habe darauf gespuckt, weil mein Ego so aufgeblasen war. Es stellt sich heraus, dass dies nicht nur schlecht, sondern auch gut sein kann. :)

 
Реter Konow:


Peter, Ihr Denken legt nahe, dass Sie noch nie in einem Team gearbeitet haben. Sie haben nicht gesehen, wie jeder seinen Teil zu einer großen Aufgabe beiträgt und wie am Ende alles zusammenkommt.

Ohne OOP war es zum Beispiel unmöglich, Windows zu erstellen und zu entwickeln.

Wenn es nicht notwendig wäre, würde ich auch versuchen, keine Klassen zu verwenden, aber als ich mich entschied, meinen Roboter in einen Mehrwährungsroboter zu verwandeln, habe ich sofort Klassen verwendet, denn es war bereits klar, was ohne OOP passieren würde.

Durch die Anwendung von Klassen ist es offensichtlich, dass die verwendeten Objektpaare derselben Klasse angehören und die gleichzeitige Arbeit mit ihnen bereits sehr einfach ist.

 
Petros Shatakhtsyan:

Peter, Ihr Denken legt nahe, dass Sie noch nie in einem Team gearbeitet haben. Sie haben nicht gesehen, wie jeder seinen Teil zu einer großen Aufgabe beiträgt und wie am Ende alles zusammenkommt.

Ohne OOP war es zum Beispiel unmöglich, Windows zu erstellen und zu entwickeln.

Wenn es nicht notwendig wäre, würde ich auch versuchen, keine Klassen zu verwenden, aber als ich mich entschied, meinen Roboter in einen Mehrwährungsroboter zu verwandeln, habe ich sofort Klassen verwendet, denn es war bereits klar, was ohne OOP passieren würde.

Durch die Anwendung von Klassen ist es offensichtlich, dass die verwendeten Objektpaare derselben Klasse angehören und die gleichzeitige Arbeit mit ihnen bereits sehr einfach ist.

Ja, ich habe nicht in einem Team gearbeitet. Mein Ansatz sollte als Experiment eines Entwicklers betrachtet werden. Ich bin nicht überzeugt, dass ich ihm folgen kann. Mein Ansatz ist zu kühn.)
 
Реter Konow:
Ja, ich war nicht Teil des Teams. Mein Ansatz sollte als Experiment eines einzelnen Entwicklers betrachtet werden. Ich will nicht dazu überreden, ihm zu folgen. Mein Ansatz ist zu unverschämt.)

Wenn ein Programmierer in die Welt des Forex einsteigt, muss er kein Profi sein und OOP kennen.

Es ist besser, die Feinheiten des Marktes zu lernen und eine profitable Handelsstrategie zu entwickeln. Dabei spielt es keine Rolle, ob Sie OOP verwenden oder nicht. Die Rentabilität des Expert Advisors wird darunter nicht leiden.

Sie müssen Ihre Energie nicht vergeuden.