OOP vs. prozedurale Programmierung - Seite 10
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ja, diese Geräte haben beides. Aber glauben Sie mir - sie sind maximal komprimiert und vielseitig, weil sie eine breite Palette von Problemen lösen.
Wenn es nicht viele Optionen gibt, können Sie mit Wenn und Aber auskommen.
Warum hat sich noch niemand dazu entschlossen, über "prozedurale Programmierung mit Funktionszeigern vs. prozedurale Programmierung ohne Funktionszeiger" zu diskutieren?
Wenn es nicht viele Optionen gibt, können Sie mit Wenn und Aber auskommen.
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. Es geht darum, den Code zu universalisieren, wobei alle zusätzlichen Syntaxtechniken und Shells einfach destruktiv sind. Das ist harte Arbeit, aber es befreit dich von allem Überflüssigen und ermöglicht dir, dich ständig weiterzuentwickeln und neue Höhen zu erreichen.
1. Warum sich die Arbeit machen, wenn man es sich leicht und einfach machen kann? Warum sollte man es schwierig machen, wenn man es einfach machen kann?
2. Wenn Sie OOP verwenden, ist die Universalisierung nicht destruktiv, sondern wird zu einer natürlichen Möglichkeit, die nichts belastet.
1. Warum sollte man sich die Arbeit machen, wenn sie leicht und einfach erledigt werden kann? Warum sollte man etwas tun, das einfach zu erledigen ist, wenn es schwierig ist?
2. Wenn Sie OOP verwenden, ist die Universalisierung nicht ruinös, sondern wird zu einer natürlichen Möglichkeit, die nichts belastet.
Mit diesem Argument können wir noch lange weitermachen. Am Beispiel einer 100-er Aufgabe habe ich meine Einstellung zu dieser Lösungsmethode aufgezeigt. Ich glaube, dass dumme Aufgaben nicht gelöst, sondern behoben werden sollten. Wenn OOP denjenigen hilft, die schwächer darin sind, Aufgaben richtig zu stellen und sie effektiv zu lösen - dann soll es ihnen auch weiterhin helfen. Aber für Leute, die Aufgaben optimieren, bevor sie sie lösen, ist OOP vielleicht einfach nicht nötig.
Wir könnten dieses Argument immer weiter ausführen. Am Beispiel einer 100-er Aufgabe habe ich meine Einstellung zu dieser Lösungsmethode aufgezeigt. Ich glaube, dass dumme Aufgaben nicht gelöst, sondern behoben werden sollten. Wenn OOP denjenigen hilft, die schwächer darin sind, Aufgaben richtig zu stellen und sie effektiv zu lösen - dann soll es ihnen auch weiterhin helfen. Aber für Leute, die Aufgaben optimieren, bevor sie sie lösen, ist OOP vielleicht einfach nicht nötig.
Sie haben nicht viel programmiert (wahrscheinlich), OOP ist wie ein Hauch von Luft.
Die meisten Menschen programmieren nicht aus Interesse oder zur Selbstentfaltung, sondern weil es ihr Job ist und das Ergebnis zählt.
Es ist nicht annähernd so bequem, aber in Bezug auf die Geschwindigkeit können Sie mit Zeigern allein auskommen.
Und Bequemlichkeit ist ein relativer Begriff.
Dmitry, natürlich verringert die Verwendung von OOP die Leistung ein wenig. Aber es sind Bruchteile von Prozent.
Aber wie OOP die Leistung eines Programmierers erhöht!
Hier ist ein kleines Beispiel aus einem meiner Projekte, es ist für die Wahrnehmung ausgeschnitten, aber eigentlich gibt es eine Menge anderer Dinge zu berücksichtigen.
Nehmen wir zum Beispiel .NET, da alle APIs aus Klassen bestehen.
Ich mag das .NET-Paradigma sehr. Übrigens gibt es ein tolles Terminal cAlgo, das Sie direkt in Visual Studio in C# schreiben können
Dimitri, natürlich verringert die Verwendung von OOP die Leistung ein wenig. Aber es sind Bruchteile von Prozent.
Wenn die Anzahl der Varianten gering ist, wird sie sich verlangsamen, aber wenn es zu viele Varianten gibt, wird es ein Vorteil sein.
Das Wichtigste ist, dass die Anzahl der Varianten in OOP keinen Einfluss auf die Leistung hat. Und bei der prozeduralen Programmierung gibt es eine Obergrenze über Ihrem Kopf.
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 von virtuellen 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 das Auftragssystem der geeignetste Ort für OOP. 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 auf einige Feinheiten stoße, an die ich mich 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 hier:
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 war sehr sinnvoll, als die abgesicherten Konten eingeführt wurden. Die Experten haben sich überhaupt nicht verä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?
Ich bin der Meinung, dass, wenn Sie sich Ihren gesamten Code buchstabengetreu merken und Sie leicht sagen können, warum diese oder jene Zeile in Ihrem Code vor einem Jahr geschrieben wurde - dann stimmt es, dass all diese OOP-Verbesserungen nur unnötige Gesten sind.
OOP ist genau dann notwendig, wenn man sich nicht an alles erinnern kann, wenn man den Code ändert - OOP ermöglicht es, Blöcke voneinander zu isolieren und die Menge der zu einem bestimmten Zeitpunkt verfügbaren Einheiten auf eine bestimmte Stelle im Programm zu beschränken.
Nun, du hast es vermasselt...
1. 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 - wir können sogar alles in eine einzige große Funktion packen.
Die Frage ist die nach der Bequemlichkeit und Effizienz der Unterstützung.
2. In MT ist der am besten geeignete Ort für OOP das Auftragssystem. Ich persönlich habe virtuelle Schnittstellen "Positionen" 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 (gehedgt oder netting).
3. 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 hier:
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 - für den Expert Advisor ändert sich nichts, es wird nur ein neuer Auftragstyp hinzugefügt, und er wird auch diese Schnittstelle unterstützen.
Das System erwies sich als sehr sinnvoll, als Hedging-Konten eingeführt wurden. Daran haben die Experten nichts geändert.
4. 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?
Ich denke, wenn Sie sich Ihren gesamten Code buchstabengetreu merken und leicht sagen können, warum diese oder jene Zeile vor einem Jahr in Ihrem Code geschrieben wurde, dann sind all diese OOP-Verbesserungen nur unnötige Gesten.
OOP ist gerade 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.
1. 1. ich stimme absolut zu. Der einzige Unterschied besteht in der Effektivität, mit der die Aufgaben auf die eine oder andere Weise gelöst werden.
2. Ich habe nicht wirklich mit dem Bestellsystem gearbeitet und kann keine technischen Probleme in seiner Konstruktion erkennen. Vielleicht gibt es die, aber wir brauchen eine konkrete Aufgabe und dann wird sich zeigen, wie effektiv ich sie ohne OOP lösen kann.
3. Meiner Meinung nach ist das angegebene Code-Beispiel von der Lesbarkeit her einfach furchtbar. Kein Wunder, dass so viele Kommentare erforderlich sind und dass man den Inhalt vergisst. Entschuldigung, aber das ist mein subjektiver erster Eindruck. Es ist einfach unheimlich.
Hier ist ein Beispiel für die Lesbarkeit meines Codes - die Funktion, die die Farbe des Elements eines Steuerelements definiert:
Wie Sie sehen können, sind Kommentare hier fast überflüssig. Mein gesamter Code ist in diesem Stil geschrieben. Ich kenne sie also sehr gut und kann mich an sie erinnern, egal welche Größe sie hat.
Meiner Meinung nach gibt es einen Fehler in Ihrem System zur Problemlösung. Das Problem selbst sollte glasklar und präzise sein, und damit auch seine Lösung. Wenn die Lösung unklar 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 eine grobe Vorstellung davon hat, wie sein System funktioniert. Und es sind schreckliche syntaktische Kunstgriffe und unnötige Einheiten in der Lösung, die ihn daran hindern, sie bis zum Ende zu verstehen.
Damit eine Lösung wirksam ist, müssen überflüssige Einheiten abgeschnitten werden, und das Problem muss ganz klar gesehen werden.