Was kann OOP-Code leisten, was prozeduraler Code nicht kann?
OOP wurde entwickelt, um wie die Natur zu arbeiten und zu denken. Stellen wir uns vor, wir wollen ein Kriegsspiel entwickeln, in dem wir Fahrzeuge mit vielen Typen, Soldaten mit vielen Fähigkeiten und Waffen mit vielen Spezifikationen haben.
Die Entwicklung dieser Art von Spiel ohne OOP wird für den Entwickler eine Qual sein, all diese Arten von Objekten im Auge zu behalten und die Datenstrukturen und den Speicher gut zu verwalten, und auch die OOP-Funktionen wie Vererbung zu simulieren wird schwer sein (obwohl es getan werden kann), OOP machte es einfacher zu denken und zu entwickeln, auch einfacher zu schreiben, zu lesen und den Code zu debuggen.
Manchmal macht OOP mehr als nötig das Verstehen und Lesen des Codes unfreundlich (mein persönlicher Standpunkt), was ich nicht mag.
In der Tat glaube ich nicht, dass es eine Aufgabe gibt, die nicht von prozeduralem Code zu OOP oder umgekehrt refaktorisiert werden kann. Der Unterschied liegt in der Wartbarkeit und Lesbarkeit des Codes. In prozeduralem Code kann man zum Beispiel auf globale und/oder lokale Daten (Variablen) verweisen. In der OOP kommt noch ein weiterer Bereich hinzu - objektinterne Variablen (Zustand). Es ist sehr einfach und natürlich, sie in OOP zu verwenden, während die prozedurale Implementierung der gleichen Logik eine Art von Umgehung mit zusätzlichem Code und Datenstrukturen erfordern würde. Mit anderen Worten: OOP ist nur eine kürzere und schönere Art der Codierung.
Wie wollen Sie einen Workaround für überladene virtuelle Funktionen einschließlich des Vererbungsbaums - dem wichtigsten Teil von OOP - bauen? Sie scheinen von Strukturen zu sprechen, nicht von OOP.
OOP wurde entwickelt, um zu arbeiten und zu denken wie die Natur. Stellen wir uns vor, wir wollen ein Kriegsspiel entwickeln, in dem wir Fahrzeuge mit vielen Typen, Soldaten mit vielen Fähigkeiten und Waffen mit vielen Spezifikationen haben.
Die Entwicklung dieser Art von Spiel ohne OOP wird ein Schmerz für den Entwickler, um alle diese Arten von Objekten zu verfolgen und die Daten-Strukturen und den Speicher gut zu verwalten, und auch die OOP-Funktionen wie Vererbung zu simulieren wird schwer sein (obwohl es getan werden kann), OOP machte es einfacher zu denken und zu entwickeln auch esier zu schreiben, lesen und den Code zu debuggen.
manchmal macht OOP mehr als nötig das Verständnis und das Lesen des Codes unfreundlich (mein persönlicher Standpunkt), was ich nicht mag
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Was kann OOP-Code, was prozeduraler Code nicht kann?
Alain Verleyen, 2016.05.22 14:03
Ich eröffne dieses Thema in der Hoffnung, nützliche Informationen über die Vorteile der objektorientierten Programmierung gegenüber der prozeduralen Programmierung zu sammeln.
Außerdem ist dieses Thema sprachunabhängig, da mql4 und mql5 die gleiche OOP-Sprache anbieten (mit Ausnahme einiger neuer, fortgeschrittener Funktionen, die in mql4 derzeit noch nicht verfügbar sind).
Ich möchte keinen "Krieg" zwischen Befürwortern und Gegnern von OOP, daher wird dieses Thema streng moderiert, verschwenden Sie bitte nicht Ihre und meine Zeit.
Bitte stellen Sie auch Beispiele und Code zur Verfügung, um Ihren Standpunkt zu illustrieren, nicht hohe Theorie oder abstrakte Konzepte.
EDIT: Obwohl dieses Thema sprachunabhängig ist, sprechen wir immer noch über Handel und mql4/mql5, also bitte keine "Kriegsspiele" oder "Äpfel und Birnen" Beispiele.
Ich bin ein großer Fan von OOP - ich kann mir nicht einmal vorstellen, dass ich zum prozeduralen MQL zurückkehren würde. Es ist einfacher, Programme komplexer zu gestalten. Wie auch immer... das Problem mit MQL ist, dass ein neuer Benutzer es schwer hat, hier anzufangen.
- Die eingebauten Ereignismethoden sind nicht OO. Man muss sich in sie einklinken, was die Deklaration der zuhörenden Objekte auf der Root-Ebene erfordert. Eines der grundlegenden OOP-Prinzipien ist mit diesem Design gefährdet.
- Es fehlen "System"-Codepakete mit gemeinsamen Mustern. Es verhindert die Erstellung kompatibler Pakete zwischen den Benutzern, und ein ernsthafter OOP-Programmierer braucht viel Zeit, um seine privaten Pakete zu erstellen. Nicht unterstützte Klassennamen-Präfixe (Paketnamen) sind nur ein kleines Problem - wenn man den externen Code sowieso nicht wiederverwenden kann.
Daher würde ich nicht empfehlen, mit dem Erlernen der OOP direkt in der MQL zu beginnen. Der Programmierer muss wissen, was er braucht, um es zum Laufen zu bringen.
Eine "if...then...else..."-Anweisung sollte die Aufgabe erfüllen.
Ach komm schon ;) Nicht wirklich ;) Wenn etwas natives die Aufgabe irgendwie seltsam erledigen könnte, dann sind es Zeiger, aber es gibt Einschränkungen in MQL. Wenn dann sonst ... der Code würde absurd werden. Und wenn du absurden Code als Antwort auf die Frage dieses Threads akzeptierst, dann ist er überhaupt obsolet ;) Stimmen Sie zu, dass Absurdität eine gute Grenze ist? Komm schon, sag ja, nur ein einziges Mal und nur für mein Ego ;)
Tut mir leid, aber nein, ich werde nicht ja sagen... ein Code erreicht entweder sein Ziel oder nicht, wenn er in Übereinstimmung mit den Spezifikationen funktioniert, gibt es nichts Absurdes.
Die Frage ist: "Was kann OOP, was prozeduraler Code nicht kann"? Stanislav sagte, dass OOP dasselbe kann wie prozedural, aber auf eine "kürzere und schönere" Weise. Ich neige dazu, dem zuzustimmen (außer bei der kürzeren Idee, aber das ist nicht so wichtig).
Die Programmierung von GUIs war das, was ich die meiste Zeit meiner Zeit als Programmierer gemacht habe. Es ist nicht möglich, eine komplette GUI zu programmieren, die in mehrere Richtungen durch if then else kommunizieren muss. Man bräuchte so viele Anweisungen, dass der Code unlesbar und am Ende auch viel zu langsam werden würde, was bedeuten würde: Ziel nicht erreicht, denn ich möchte nicht gezwungen sein, nach jedem Klick eine Tasse Kaffee zu trinken, bis ich das Ergebnis sehe.
Da eine CPU keine Ahnung von OOP hat, kann man natürlich auch alles ohne programmieren, indem man nur Zeiger und komplexe Arrays verwendet. Aber das ist absurd. Ich könnte auch 10000 Leute einstellen, die meinen Bildschirminhalt quasi in Echtzeit auf Film zeichnen und sequentiell per Lichtprojektor an die Wand beamen. Ist das auch zielführend?
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Ich eröffne dieses Thema in der Hoffnung, nützliche Informationen über die Vorteile der objektorientierten Programmierung gegenüber der prozeduralen Programmierung zu sammeln.
Außerdem ist dieses Thema sprachunabhängig, da mql4 und mql5 die gleiche OOP-Sprache anbieten (mit Ausnahme einiger neuer, fortgeschrittener Funktionen, die in mql4 derzeit noch nicht verfügbar sind).
Ich möchte keinen "Krieg" zwischen Befürwortern und Gegnern von OOP, daher wird dieses Thema streng moderiert, verschwenden Sie bitte nicht Ihre und meine Zeit.
Bitte stellen Sie auch Beispiele und Code zur Verfügung, um Ihren Standpunkt zu illustrieren, nicht hohe Theorie oder abstrakte Konzepte.
EDIT: Obwohl dieses Thema sprachunabhängig ist, sprechen wir immer noch über Handel und mql4/mql5, also bitte keine "Kriegsspiele" oder "Äpfel und Birnen"-Beispiele.