OOP vs. prozedurale Programmierung - Seite 35
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
Seien Sie vorsichtig, wir sprechen hier nicht von internen MT-Variablen, sondern von internen Objektvariablen, die Sie isoliert haben, um zu verhindern, dass ihre Werte beim Debuggen und Schreiben von Code gelesen werden können...
Das ist, was ich sage - wenn Sie einen EA debuggen - brauchen Sie nicht MT's interne Variablen?
Ähnlich verhält es sich in diesem Fall mit dem Handelsprozessor-Objekt - wenn Sie z.B. die Methodik der Auftragserteilung in Ihrem TS debuggen - warum sollten Sie Zugriff auf die internen Variablen des Handelsprozessors haben?
Andrei ist noch klinischer als Peter oder Sansanych, Sie verschwenden Ihre Zeit.
Junge Menschen müssen unterrichtet werden.
Außerdem gibt es vielleicht einen rationalen Grund für das, was meine Gegner sagen. Wenn ich, sagen wir, ein solches Gedächtnis wie Peter hätte, würde ich mich vielleicht auch nicht mit der PLO beschäftigen.
An anderen Stellen ist es dasselbe - wenn Daten benötigt werden, muss dieser Block die entsprechende Schnittstelle bereitstellen.
Das ist es, was ich meine... Anstatt einfach nur den Wert der gewünschten Variablen zu sehen, müssen Sie sich überlegen, wie Sie eine geeignete Schnittstelle mit ihr verbinden und sie dann wieder aushängen können. :)
Sieht aus wie eine Aktivität für Programmier-Masochisten :)
Ja... etwas Besseres als einen Schwanz gibt es nicht :) Die Idee ist, eine adäquate Programmiersprache zu haben, die das Debuggen und das Schreiben von Code mit minimalen Gesten erleichtert, aber hier haben wir eine völlig entgegengesetzte Situation...
Es handelt sich nicht um eine "gegensätzliche Situation". Es stimmt, dass OOP etwas zusätzliche Arbeit erfordert. Dies wird jedoch durch die Bequemlichkeit der Unterstützung und der Systemanpassung mehr als wettgemacht.
Auch hier - um auf den Handelsprozessor zurückzukommen - wird er in vielen TS geschrieben und verwendet. Es ist die Isolierung seiner Interna von der TS, und die Arbeit nur durch eine virtuelle Schnittstelle ermöglicht nicht darüber nachzudenken, welche Variablen in ihm sind und was sie gleich sind. Wenn Fehler entdeckt werden, befinden sie sich innerhalb des Prozessors und müssen in einer echten Klasse behoben werden, ohne dass die TS-Klassen davon betroffen sind. Wenn der Fehler im TS selbst liegt, hat er keine Auswirkungen auf die Variablen des Handelsprozessors.
Die Kapselung ist eigentlich eine sehr nützliche Technik.
Ja... man kann nicht anders, als sich zu fragen, was zum Teufel da drin ist :) Die Idee ist, eine adäquate Programmiersprache zu haben, die das Debuggen und das Schreiben von Code mit minimalen Gesten erleichtert, aber hier haben wir eine völlig entgegengesetzte Situation...
Die Fehlersuche wird durch die Aufteilung der Verantwortung in den einzelnen Klassen erleichtert: Jede Klasse ist für ihren eigenen Satz von Variablen verantwortlich. Keine andere Klasse hat das Recht, ihre Werte zu ändern. Dadurch werden die meisten Probleme bereits in der Kompilierungsphase beseitigt. Und der Zugriff auf Variablen von jeder beliebigen Stelle im Programm aus ist vergleichbar mit einem Dutzend Steuerrädern auf einem Schiff.
Junge Menschen müssen unterrichtet werden.
Darüber hinaus gibt es vielleicht eine rationale Grundlage für das, was meine Gegner sagen. Wenn ich zum Beispiel so ein Gedächtnis hätte wie Peter, würde ich mich auch nicht mit OOP herumschlagen.
1. Wie stark hat sich die Rentabilität Ihrer Berater durch den Einsatz von OOPs erhöht?
2. Wie stark hat sich die Rentabilität Ihrer Berater durch den Einsatz von OOP verringert?
Das ist es, was ich meine... Anstatt einfach nur den Wert der gewünschten Variablen zu sehen, müssen Sie sich überlegen, wie Sie eine geeignete Schnittstelle mit ihr verbinden und sie dann wieder aushängen können. :)
Sieht aus wie eine Aktivität für Programmier-Masochisten :)
Wie Sie sehen, hat Peter Ihnen oben eine seiner Strukturen gezeigt, nicht die größte.
Können Sie es leicht herausfinden?
Genau dieser "Masochismus" ist es, der es Ihnen ermöglicht, erstens nicht in den funktionierenden Code einzudringen und ihn nicht zu zerstören. Und zweitens ermöglicht es Ihnen, die Systemstruktur sofort zu entwerfen, so dass Sie die erforderlichen Daten in den entsprechenden Blöcken des Programms bereitstellen können.
Ja, es gibt tatsächlich Situationen, in denen man plötzlich feststellt, dass es fast unmöglich ist, die benötigten Daten zu bekommen. Sie verbergen sich hinter mehreren virtuellen Schnittstellen. Diese Situation zeigt jedoch deutlich, dass das System ursprünglich falsch konzipiert war, da es die Übermittlung dieser Daten nicht vorsah. Diese Situation ist in der Tat sehr unangenehm. Wir müssen entweder eilig "Krücken" in Form von zusätzlichen Schnittstellen bauen oder das ganze System umstrukturieren.... Dies motiviert den Programmierer dazu, sich mehr Gedanken über die Systemarchitektur zu machen.
Wenn Sie weniger Emotionen und Reflexivität und mehr Spezifität in der Essenz der Diskussion hätten - Sie wären es nicht wert. :)
Diese Diskussion hat keine Substanz mehr. Sie sind im Grunde genommen stümperhaft und tun so, als wären Sie begriffsstutzig.
Wenn ein Moderator die letzten paar Seiten als irrelevant für das Thema des Threads und die Programmierung im Allgemeinen schließt, werde ich in den seltensten Fällen seine Maßnahmen unterstützen.
1. Wie stark hat sich die Rentabilität Ihrer EAs durch den Einsatz von OOPs erhöht?
2. Um wie viel hat sich die Fehlerquote Ihrer Berater durch den Einsatz von OOP verringert?
1. Nicht um wie viel. Die Rentabilität hängt nicht vom OOP ab.
2. Meiner Meinung nach um eine Größenordnung (das Zehnfache). Der Hauptvorteil von OOP liegt jedoch in der Codeunterstützung. Jetzt bin ich sehr schnell in der Lage, den Code zu verstehen, den ich vor einem Jahr oder mehr geschrieben habe. Ich erinnere mich noch gut daran, wie ich meine frühen ANSI-C-Programme im rein prozeduralen Stil verstanden habe. Es war viel schwieriger.
Die Fehlersuche wird durch die Aufteilung der Verantwortung in den einzelnen Klassen erleichtert: Jede Klasse ist für ihren eigenen Satz von Variablen verantwortlich. Keine andere Klasse hat das Recht, ihre Werte zu ändern. Dadurch werden die meisten Probleme bereits in der Kompilierungsphase beseitigt. Und der Zugriff auf Variablen von jeder Stelle des Programms aus ist vergleichbar mit einem Dutzend Steuerrädern auf einem Schiff.
Ich kann nicht verstehen, warum ich so etwas bei meiner Arbeit noch nie erlebt habe. Warum die Probleme mit der Begrenzung des Variablenzugriffs durch EINEN Entwickler in einem nicht sehr großen Programm? Es gäbe 100 Entwickler, die jeweils 100 Funktionen schreiben. Theoretisch könnte sie erfunden werden. Aber praktisch hat sich die Programmierung seit fast 40 Jahren zu OOP entwickelt, es wurden Berge von Code geschrieben und nie etwas Vergleichbares gehört.