OOP vs. prozedurale Programmierung - Seite 11

 
Реter Konow:

Meiner Meinung nach gibt es einen Fehler in Ihrem System zur Lösung von Problemen. Das Problem selbst sollte glasklar und präzise sein, und damit auch seine Lösung. Wenn die Lösung wolkig ist und mit den Worten "Das System hat sich als sehr vernünftig erwiesen" definiert wird (wie kann es in 270 kb Code vernünftig sein?!), bedeutet dies, dass der Autor ungefähr weiß, wie sein System funktioniert. Und es sind die beängstigenden syntaktischen Konstruktionen und überflüssigen Einheiten in der Lösung, die ihn daran hindern, sie bis zum Ende zu verstehen.

Die Angemessenheit liegt in der "Vorhersagekraft" - eine signifikante Änderung der Arbeitsprotokolle erforderte keine Änderungen des Kodex der für die Logik ihrer Arbeit verantwortlichen Experten. Die Code-Änderung erfolgte nur an der Stelle, an der das Terminal auf einer niedrigen Ebene direkt bedient wurde.


Der angegebene Code zeigt sehr gut, wie alle OOP-Hacks gut durch "funktionale Hacks" ersetzt werden können. Das ist genau das, was ich oben gesagt habe - es kann in beide Richtungen geschrieben werden.

Aber wenn ich mir Ihren Code ansehe, sehe ich, dass Sie viel mehr im Speicher behalten müssen. Sagen wir, in den meisten Ihrer Wenns bin ich in einem Moment "ertrunken". Sie sind korrekt, aber wenn ich diesen Code pflegen müsste, würde ich vor jeder Bedingung ein paar Zeilen mit Kommentaren einfügen, was diese Prüfung bewirkt und warum diese Felder im Array verwendet werden. Ähnlich wie der Kommentar vor der Deklaration der CTradePositionI-Schnittstelle in meinem Code. Außerdem würden mich komplexe Bedingungen auch persönlich sehr belasten.

Ich persönlich würde mehr Fehler in Ihrem Code machen, und es wäre schwieriger, sie zu erkennen. Das heißt, trotz der Korrektheit und Logik eines solchen Codes wäre es für mich schwieriger, ihn zu pflegen, als wenn ich alles im OOP-Stil geschrieben hätte.

Im OOP-Stil würde ich Schnittstellen von Fenstern, Teilen von Leinwänden, Elementen, Leinwänden deklarieren, dann würde ich echte Klassen dieser Objekte schreiben, und dann würde ich Zeiger auf diese Schnittstellen in den richtigen Blöcken ausgeben, und speziell mit diesen Entitäten arbeiten, die im Moment benötigt werden - alles andere wäre zu diesem Zeitpunkt nicht verfügbar. So müssen Sie sich nicht merken, was wozu gehört und wer für was verantwortlich ist. Wenn Sie die einfachste Schnittstelle erhalten, die aus ein paar Funktionen besteht, arbeiten Sie einfach damit, und der Rest ist unnötig und für Sie nicht verfügbar. Sie brauchen sich überhaupt nichts zu merken.

 
George Merts:

Nun, du hast es vermasselt...

Es ist klar, dass jede Aufgabe sowohl im OOP-Stil, mit der Zuweisung von Schnittstellen, dem Aufbau einer Vererbungshierarchie und der Deklaration virtueller Funktionen, als auch im rein prozeduralen Stil gelöst werden kann - man kann sogar alles in eine einzige große Funktion stecken.

Die Frage ist die nach der Bequemlichkeit und Effizienz der Unterstützung.

In MT ist der am besten geeignete Ort für OOP das Auftragssystem. Ich persönlich habe virtuelle Schnittstellen für "Position" und "Positionskomponenten". Eine "Position" ist eine Reihe von Aufträgen in MT4 oder eine Reihe von Positionen in MT5. "Positionskomponente" ist ein einzelner Auftrag oder eine einzelne MT5-Position (Hedge oder Netting).

Hier ist die eigentliche Schnittstellendatei(Retag Konow, Sie können die Anzahl der Kommentare im Vergleich zur Menge des Codes schätzen, und ich füge sie regelmäßig hinzu, wenn ich feststelle, dass ich mich an einige Feinheiten nicht erinnere. Ich vergesse zum Beispiel regelmäßig, welche realen Objekte eine "Positionskomponente" darstellen. Ich brauche mir das nicht zu merken - der Expert Advisor arbeitet mit Komponenten entsprechend der Schnittstelle, und was sich in Wirklichkeit hinter dieser Schnittstelle befindet, spielt keine Rolle. Aber ich muss während der Änderung darauf zurückkommen - deshalb brauche ich den ersten Kommentar in dieser Datei sehr oft):

Die Datei für die Schnittstelle der Handelskomponente sieht wie folgt aus (ich habe sie bereits oben angegeben, aber ich wiederhole sie:

Entsprechend dieser Schnittstellen habe ich sowohl das MT4- als auch das MT5-Ordersystem sowohl für reale als auch für historische Aufträge implementiert.

Der Expert Advisor, der eine Position anfordert, erhält diese Schnittstelle und muss den Unterschied zwischen MT4- und MT5-Aufträgen nicht berücksichtigen. Und wenn ein neuer Auftragstyp hinzugefügt oder die Reihenfolge der Arbeit mit ihnen geändert wird, ändert sich für den Expert Advisor nichts, nur die neue Auftragstypklasse wird hinzugefügt, und sie wird auch diese Schnittstelle unterstützen.

Das System erwies sich als sehr clever, als Hedging-Konten eingeführt wurden. Für die Experten hat sich daran nichts geändert.

Reg Konow, wie gehen Sie mit dem Unterschied zwischen den Ordertypen in MT4 und MT5 um?

Wenn eine neue Kontoart eingeführt wird (zusätzlich zu Hedge und Netting) - welche Änderungen müssen dann vorgenommen werden, und zwar an derselben Stelle?

Wenn Sie sich Ihren gesamten Code buchstabengetreu merken und leicht erkennen können, warum diese oder jene Zeile vor einem Jahr in Ihrem Code geschrieben wurde, dann sind all diese OOP-Verbesserungen meiner Meinung nach wirklich nur unnötige Gesten.

OOP ist genau dann notwendig, wenn man sich nicht alles merken kann, wenn man den Code ändert - OOP ermöglicht es, Blöcke voneinander zu isolieren, um die Menge der zu einem bestimmten Zeitpunkt verfügbaren Einheiten auf eine bestimmte Stelle im Programm zu beschränken.


George, du schreibst manchmal so einen Mist über Frauen, aber respektiere den Code ))))

 
George Merts:

Die Angemessenheit liegt in der "Vorhersagekraft" - eine wesentliche Änderung der Betriebsprotokolle - erforderte keine Änderungen am EA-Code, der für die Logik ihres Betriebs verantwortlich ist. Die Code-Änderung wurde nur an der Stelle vorgenommen, an der das Terminal auf einer niedrigen Ebene direkt bedient wird.


Der angegebene Code zeigt sehr gut, wie alle OOP-Hacks gut durch "funktionale Hacks" ersetzt werden können. Das ist genau das, was ich oben gesagt habe - es kann in beide Richtungen geschrieben werden.

Aber wenn ich mir Ihren Code ansehe, sehe ich, dass Sie viel mehr im Speicher behalten müssen. Sagen wir, in den meisten Ihrer Wenns bin ich in einem Moment "ertrunken". Sie sind korrekt, aber wenn ich diesen Code pflegen müsste, würde ich vor jeder Bedingung ein paar Zeilen mit Kommentaren einfügen, was diese Prüfung bewirkt und warum diese Felder im Array verwendet werden. Ähnlich wie der Kommentar vor der Deklaration der CTradePositionI-Schnittstelle in meinem Code. Außerdem würden mich komplexe Bedingungen auch persönlich sehr belasten.

Ich persönlich würde mehr Fehler in Ihrem Code machen, und es wäre schwieriger, sie zu erkennen. Das heißt, bei aller Korrektheit und Logik eines solchen Codes wäre seine Unterstützung für mich schwieriger, als wenn ich alles im OOP-Stil geschrieben hätte.

Im OOP-Stil würde ich Schnittstellen von Fenstern, Teilen von Leinwänden, Elementen, Leinwänden deklarieren, dann würde ich echte Klassen dieser Objekte schreiben, und dann würde ich Zeiger auf diese Schnittstellen in den richtigen Blöcken ausgeben, und speziell mit diesen Entitäten arbeiten, die im Moment benötigt werden - alles andere wäre zu diesem Zeitpunkt nicht verfügbar. So müssen Sie sich nicht merken, was wozu gehört und wer für was verantwortlich ist. Wenn Sie die einfachste Schnittstelle erhalten, die aus ein paar Funktionen besteht, arbeiten Sie einfach damit, und der Rest ist unnötig und für Sie nicht verfügbar. Sie müssen sich überhaupt nichts merken.

In meinem Code ist die große Anzahl von Schriftarten und ihre Verschachtelung auf das komplexe Verhalten der verschiedenen Steuerelementdefinitionen bei verschiedenen Ereignissen und in verschiedenen Zuständen zurückzuführen. Diese Funktion deckt jedoch alle diese Optionen ab und "bedient" die gesamte GUI. Wenn ein Element neu gezeichnet wird, wird die Farbe des Teils durch den ursprünglichen Farbwert im Kernel und diese Funktion bestimmt.

P.S. In Bezug auf OOP oder prozeduralen Stil, dann - "Jedem das Seine" (c).

 
Alexey Volchanskiy:

Georges, schreiben Sie manchmal eine solche Klinik über Frauen, sondern respektieren den Code )))

Was den Code angeht - ich fühle mich geschmeichelt. (Wirklich, kein Scherz).

Und was die Mädels angeht... Ich bin nicht so ein Casanova wie du... Ich bin derjenige, der sich zurückhält und nicht sagt, was ich denke... Ich hatte und habe in dieser Hinsicht immer viele Probleme, obwohl mir ein angenehmes Privatleben immer sehr wichtig war... Es ist gut, dass mir das Glück manchmal hold war, und es gibt immerhin etwas, an das man sich erinnern kann.

 
George Merts:

Was den Code angeht - ich fühle mich geschmeichelt. (Wirklich, kein Scherz).

Und über Frauen... Ich bin nicht so ein Casanova wie du... Ich bin derjenige, der sich zurückhält und nicht sagt, was ich denke... Ich hatte und habe in dieser Hinsicht immer viele Probleme, obwohl mir ein angenehmes Privatleben immer sehr wichtig war... Es ist gut, dass mir das Glück manchmal hold war, und es gibt immerhin etwas, an das man sich erinnern kann.


Es ist nur so, dass wir eine andere Einstellung zu Frauen haben. Ich denke, ihnen sollte geholfen werden. Ja, sie sind launisch, haben ihre eigenen Macken, sind unbeständig in ihren Leidenschaften, usw. Man darf sie nur nicht ernst nehmen, sonst kommt es zu moralischen Tragödien.

 
George Merts:

Nun, du hast es vermasselt...

Es ist klar, dass jede Aufgabe sowohl im OOP-Stil, mit Zuweisung von Schnittstellen, Aufbau einer Vererbungshierarchie, Deklaration virtueller Funktionen, als auch im rein prozeduralen Stil gelöst werden kann - man kann sogar alles in eine einzige große Funktion stecken.

Die Frage ist die nach der Bequemlichkeit und Effizienz der Unterstützung.


Wir können es tun, aber die Effizienz des Betriebs ist unterschiedlich. Wir sprechen hier nicht von Unterstützung, das ist zu relativ.

Es gibt Aufgaben, die verfahrenstechnisch nicht optimal gelöst werden können.

 
Alexey Volchanskiy:

Wir haben einfach eine andere Einstellung zu Frauen. Ich denke, ihnen sollte geholfen werden. Ja, sie sind launisch, haben ihre Macken, sind wankelmütig in ihren Vorlieben, usw. Man darf sie nur nicht ernst nehmen, sonst kommt es zu moralischen Tragödien.


Alexej, haben Sie ein Experiment durchgeführt, um herauszufinden, wie unendlich groß der Wunsch einer Frau nach Hilfe ist? Haben Sie die Genugtuung der Hilfe erfahren und wie lange hat sie gedauert?

 
Реter Konow:


Ich nehme an, Sie verwenden nicht einmal Strukturen zum Speichern von Daten? Ihre mehrdimensionalen Arrays wecken Erinnerungen an das alte MQL4, wo man mangels Strukturen solche Lösungen verwenden musste. Aber was bringt das jetzt? Zum Beispiel

 int Элемент                     =  G_CORE[Окно][Деталь_полотна][_MAIN_ELEMENT];
 int Состояние_детали            =  G_CORE[Окно][Элемент][_CURRENT_STATE]; 

können Sie ersetzen durch

 int Элемент                     =  G_CORE[Окно][Деталь_полотна].MAIN_ELEMENT;
 int Состояние_детали            =  G_CORE[Окно][Элемент].CURRENT_STATE; 

Das ist kürzer, sicherer und schneller. Im ersten Fall gibt es in der Kompilierungsphase keine Kontrolle über die Werte der Array-Indizes, die Sie an das Programm übergeben. Und dann müssen Sie alle Arten von "array out of range" zur Laufzeit bereinigen - und das ist das Beste. Schlimmer ist es, wenn der Index zwar akzeptabel, aber falsch ist. Deshalb ist es eine gute Programmierpraxis, den Compiler so weit wie möglich einzubeziehen und Fehler bereits bei der Kompilierung zu erkennen und nicht erst zur Laufzeit, wie in Ihrem Fall.

Ja, im Moment sind Sie gut darin, sich zu merken, welche Werte Sie wohin füttern müssen. Aber das liegt wahrscheinlich daran, dass Sie ständig mit diesem Projekt beschäftigt sind. Versuchen Sie einmal, ein halbes Jahr lang eine Pause einzulegen, und spüren Sie den Unterschied. Einige Leute haben das bereits erwähnt. Oder glaubst du, wir sind alle Sklerotiker oder so? :) Es ist eine übliche Sache für einen Programmierer...

Es geht also darum, die Wahrscheinlichkeit zu minimieren, dass man sich selbst in den Fuß schießt. Ich empfehle dringend, dass Sie Ihre eigenen Typen mit enum anstelle des allgegenwärtigen int erstellen. Und sie müssen nicht unbedingt Aufzählungswerte haben, die Hauptsache ist, dass es sich um einen separaten, unabhängigen Typ handelt, der vom Compiler kontrolliert wird und es nicht erlaubt, Funktionsargumente usw. zu vertauschen.

 

Ich schreibe nur und ausschließlich OOP.

Damals, um 1900, konnte ich mich nicht damit anfreunden - Pascal 6.0, dann Borland C++ 4.5. Aber wenn ich es beherrsche, kann ich mir nichts anderes mehr vorstellen - es ist jetzt so einfach und bequem.

 
Alexey Navoykov:

Ich nehme an, Sie verwenden nicht einmal Strukturen zum Speichern von Daten? Ihre mehrdimensionalen Arrays wecken Erinnerungen an das alte MQL4, wo man mangels Strukturen solche Lösungen verwenden musste. Aber was bringt das jetzt? Zum Beispiel

können Sie ersetzen durch

Das ist kürzer, sicherer und schneller. Im ersten Fall gibt es in der Kompilierungsphase keine Kontrolle über die Werte der Array-Indizes, die Sie an das Programm übergeben. Und dann müssen Sie alle Arten von "array out of range" zur Laufzeit bereinigen - und das ist das Beste. Schlimmer ist es, wenn der Index zwar akzeptabel, aber falsch ist. Deshalb ist es eine gute Programmierpraxis, den Compiler so weit wie möglich einzubeziehen und Fehler bereits bei der Kompilierung zu erkennen und nicht erst zur Laufzeit, wie in Ihrem Fall.

Ja, im Moment sind Sie gut darin, sich zu merken, welche Werte Sie wohin füttern müssen. Aber das liegt wahrscheinlich daran, dass Sie ständig mit diesem Projekt beschäftigt sind. Versuchen Sie, eine Pause von, sagen wir, sechs Monaten einzulegen, und Sie werden den Unterschied spüren. Einige Leute haben das bereits erwähnt. Oder glaubst du, wir sind alle Sklerotiker oder so? :) Es ist eine übliche Sache für einen Programmierer...

Es geht also darum, die Wahrscheinlichkeit zu minimieren, dass man sich selbst in den Fuß schießt. Ich empfehle dringend, dass Sie Ihre eigenen Typen mit enum anstelle des allgegenwärtigen int erstellen. Und sie müssen keine Aufzählungswerte haben, die Hauptsache ist, dass es sich um einen separaten, unabhängigen Typ handelt, der vom Compiler kontrolliert wird und es nicht erlaubt, Funktionsargumente usw. zu vertauschen.

Ich habe Ihre Beiträge in anderen Threads gelesen und festgestellt, dass Sie ein großer Experte in Sachen Programmierung sind. Natürlich bin ich kein solcher und behaupte auch nicht, einer zu sein. Ich betrachte mich jedoch als Spezialist für die Lösung von Aufgaben als solche. Sind Sie nicht auch der Meinung, dass die Wirksamkeit der Lösung das Wichtigste ist?

Die Überfrachtung der Syntax und die Komplexität der Regeln haben nie dazu beigetragen, die Lösung effizient zu halten. Es war die Einfachheit und Kürze, die sich in der Prägnanz, Universalität und Lesbarkeit der Codeblöcke ausdrückte, die dies bewirkte.

Meine Regeln beim Programmieren sind weniger Code, weniger Regeln, weniger Syntax und weniger Kommentare auf Kosten der Verwendung der Muttersprache und sinnvoller Namen von Variablen und Funktionen.

Meine Hauptthese lautet: "Wenn man bei einer Lösung auf etwas verzichten kann, sollte man es auf jeden Fall weglassen".

Ich glaube nicht, dass es hier überhaupt sklerotische Menschen gibt.) Wenn man sich die angegebenen Codes ansieht, wird klar, warum sie leicht vergessen werden. Schon allein die Tatsache, dass man in einer Fremdsprache programmiert, spielt eine Rolle. Wenn man in seiner eigenen Sprache programmiert, fühlt es sich ganz anders an. Sie spüren Kraft und Freiheit statt Spannung und Zwang. Eine Fremdsprache ist anstrengender, man braucht mehr Zeit, um sie zu verinnerlichen, und sie geht einem schneller aus dem Kopf. Es ist nur ein "biologischer Faktor".

Daher halte ich es (vernünftigerweise) für ineffizient, OOP im Allgemeinen zur Lösung meiner Aufgaben zu verwenden. Jede Menge Regeln, Syntax und alles in einer Fremdsprache. Auf diese Weise kann sich das Talent nicht richtig entfalten, was zu einem schlechteren Ergebnis führt.

Grund der Beschwerde: