Gemeinkosten für die PLO - Seite 2
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
Natürlich muss die schöne OOP mit Ressourcen und viel Zeit für die Fehlersuche bezahlt werden. OOP ist nur als praktischer Text-Wrapper oder bei minimaler Verwendung in der Laufzeitinitialisierung sinnvoll... Eigentlich war OOP nur eine Marketingmaßnahme von Microsoft, um die Kosten für die Arbeitszeit der Programmierer zu erhöhen und den Kauf fortschrittlicherer Geräte zu fördern. Und sie sind selbst nicht dumm und schreiben die gesamte Software in C und Assembler.
Was für ein Schwachsinn.
jeder weiß, dass MS-Programmierer direkt in Maschinencode schreiben
jeder Programmierer hat ein Buch mit den Codes der Prozessoren auf seinem Schreibtisch liegen und brennt die Codes einfach auf Lochkarten
Bill Gates kann ein Betriebssystem in seinem Kopf kompilieren.)
Was für ein Schwachsinn.
Jeder weiß, dass MS-Programmierer direkt in Maschinencode schreiben
Ihre Clownerie ist nicht ganz klar, es ist bekannt, dass Assembler-Einfügungen verwendet werden, um die Codeleistung zu verbessern...
Ich kann vermuten, dass OOP in Terminal auf ein Minimum oder gar nicht verwendet wird, weil es schwierig ist, solche kompakten Dateien ohne große externe Bibliotheken wie in Dotnet zu erhalten...
Haben Sie irgendwelche sinnvollen Argumente zum Kern des Gesagten?
Prüfen. Alexej reagiert tatsächlich nur gefühlsmäßig. Und die Einwände lauten im Wesentlichen wie folgt.
OOP ist sehr nützlich, wenn Sie einen komplexen Code unterstützen müssen.
Sicherlich macht es keinen Sinn, alle OOP-Tricks auf eine Indikator-MA anzuwenden. Wenn jedoch grundlegende Klassen geschrieben werden - selbst für MA - ist der OOP-Ansatz mindestens so gut wie ein gewöhnlicher, prozeduraler Ansatz.
Der Hauptvorteil von OOP zeigt sich in der Unterstützung von entwickelten Objektstrukturen. Wenn die Kapselung dafür sorgt, dass man nicht jedes Mal alle Nuancen der überladenen Funktionen verstehen muss. Wenn sie auf Polymorphismus basiert, wird dieWiederverwendung von Code viel höher.
Das Wesen von OOP ist näher an der realen Welt, in der jedes Objekt immer mit seinen Eigenschaften verbunden ist und bestimmte Regeln der Interaktion mit der Umgebung hat.
Was die "erhöhten Kosten für Arbeitsstunden" betrifft, so stimmt dies nicht. Sicherlich erfordert der Entwurf eines Systems im OOP-Stil etwas mehr Arbeit als ein prozedural orientierter Ansatz. Diese zusätzlichen Kosten werden jedoch durch die Bequemlichkeit der Pflege und Änderung des geschriebenen Codes mehr als ausgeglichen.
Ich persönlich schreibe sehr kleine "kniegeschriebene" Indikatoren ohne Objekte. Wenn jedoch etwas mehr (zumindest plattformübergreifend) erforderlich ist, verwende ich immer den OOP-Stil und bestehende Praktiken in Objektbibliotheken.
Ihre Clownerie ist nicht ganz klar, wir wissen, dass Assembler-Inserts verwendet werden, um die Codeleistung zu verbessern...
Ich kann davon ausgehen, dass das Terminal minimale oder keine OOP verwendet, weil ohne riesige externe Bibliotheken wie in Dotnet ist es schwer, solche kompakten Dateien zu erhalten...
1. OOP - es hilft sehr, wenn Sie eine Art von komplexem Code unterstützen müssen.
2. Es macht natürlich keinen Sinn, alle OOP-Tricks für Indikator-MA anzuwenden. Obwohl, wenn grundlegende Klassen geschrieben werden - sogar für MA - ist es immer noch ein OOP-Ansatz, zumindest nicht schlechter als der übliche prozedurale Ansatz.
3. Der Hauptvorteil von OOP zeigt sich in der Unterstützung von entwickelten Objektstrukturen.
1. z.B.? Einprägsame Slogans sind gut, aber es ist nicht klar, was sie genau bedeuten...
2. Es wurde bereits gesagt, dass OOP als Textumhüllung gut hilft, aber das liegt daran, dass es in der prozeduralen Programmierung nicht auf den neuesten Stand gebracht worden ist.
3) Warum müssen wir diese "entwickelten Strukturen" vervielfältigen? Dies wird sich negativ auf die Leistung des Codes auswirken, und es ist nicht sicher, dass es einfacher und schneller sein wird, Fehler darin zu finden.
Moderne Compiler optimieren um ein Vielfaches besser als ein durchschnittlicher oder sogar guter Programmierer.
Vielleicht einige einfache und triviale Dinge können, aber nur, weil Menschen setzten sich hin und schrieb den Algorithmus manuell, aber wenn etwas nicht-Standard, ist es bei weitem nicht sicher, vor allem, wenn OOPesheh Funktionen gibt es gefunden.
Bei Treibern wird zwar Assebler verwendet, aber nicht wegen der Geschwindigkeit, sondern weil es einfacher ist, mit der Hardware zu arbeiten..,
Nun, die Menschen sind nicht dumm - warum sollten sie etwas Kompliziertes und Verwirrendes wollen, das auch noch langsam ist?
Und zum Beispiel? Einprägsame Slogans sind schön, aber es ist schwer zu verstehen, worüber genau wir reden... 3.
2. Es wurde bereits gesagt, dass OOP als Textumhüllung gut ist, aber das liegt daran, dass es in der prozeduralen Programmierung nicht auf den neuesten Stand gebracht worden ist.
3) Warum sollten wir diese "entwickelten Strukturen" vermehren? Es wäre schrecklich für die Leistung des Codes und es ist nicht die Tatsache, dass es einfacher und schneller sein wird, Fehler darin zu finden.
1. Sie benötigen zum Beispiel ein Array von Objekten. Dies könnte prozedural oder auf der Grundlage von CArrayObj und CObjest geschehen. Die Probleme beginnen, wenn Sie das Verhalten z. B. beim Hinzufügen oder Entfernen von Objekten oder beim Sortieren von Objekten ändern müssen. In der OOP ist die Unterstützung für ein Zeigerarray und die Arbeit mit ihm in den Basisobjekten enthalten. Die Änderung von Nachfolgeobjekten, die tatsächlich in dem Array enthalten sind, hat keine Auswirkungen. Im prozeduralen Stil - das Ändern von realen Objekten, die tatsächlich in einem Array enthalten sind - betrifft in der Regel viel mehr Stellen, zumindest weil wir Änderungen der Größe der Objekte berücksichtigen müssen. Das wird leichter zu Fehlern führen.
Plattformübergreifend - auch viel bequemer zu organisieren im OOP-Stil. Bei der Anfrage, sagen wir, einer Handelsposition, erhalten wir eine Schnittstelle, und es spielt keine Rolle, auf welcher Plattform wir arbeiten - die Schnittstelle bietet virtuelle Funktionen, über die wir alle Daten zu allen Aufträgen (für MT4) oder Positionen (MT5) abrufen können, und vom Standpunkt des Experten aus gibt es keinen Unterschied. Der Expert Advisor muss nicht wissen, auf welcher Plattform er arbeitet.
2. Nun, "Fertigstellung in prozeduraler Programmierung" bedeutet "Schreiben von Objekten-Prozeduren", d.h. Schaffung einiger Verbindungen zwischen Daten und Prozeduren, die Objekte in OOP darstellen.
3. und dann haben wir, sagen wir, eine Reihe von Auftragsarten, die viele Gemeinsamkeiten haben. Es wäre sinnvoll, ein Objekt COrderInfo zu erstellen, das das Basisobjekt wäre und dessen Nachkommen verschiedene Arten von Aufträgen darstellen würden. In diesem Fall unterstützt der Trade Processor (ich habe die Klasse CTradeProcessor) automatisch genau den Auftrag, der ihm übergeben wurde, durch die Prozeduren, die zur Verarbeitung dieses Auftrags erforderlich sind.
Es ist einfacher, Fehler zu finden, wenn es weniger Querverweise gibt. Genau das wird durch Kapselung und Polymorphismus gewährleistet. Wir fordern die Schnittstelle für die Handelsposition (CTradePositionI) an, und alle Verbindungen mit realen Klassen, die diese Position repräsentieren (CMT4PositionInfo, CMT5PositionInfo), werden nur über diese Schnittstelle ausgeführt, und genau das trägt zu einer einfacheren Fehlerkorrektur bei, als wenn wir direkt mit realen Funktionen arbeiten, die Handelspositionsdaten zurückgeben.