Was kann OOP-Code leisten, was prozeduraler Code nicht kann? - Seite 4

 
Doerk Hilger:

Erwartest du wirklich, dass jemand, der professionell arbeitet, eine Compex-Bibliothek einfach so als "Beweis" postet? ;) Ich könnte dir einen Link zu etwas Fertigem posten, das hier auf dem Markt nicht verkauft werden kann, aber Alain wird mich treten, wenn ich das tue ;) Du kannst mein Profil besuchen und einen Blick auf das Wandbild werfen, um eine Idee zu bekommen oder mir eine PM schicken.

Eine andere Plattform? Sie werden keine andere Plattform mit einem so leistungsfähigen Compiler finden. Ganz und gar nicht.

@James Cater - vielen Dank für Ihren Kommentar.

Es gibt noch andere Plattformen als MT, und ob der Compiler nun mehr oder weniger leistungsfähig ist, ist mir eigentlich egal, solange ich einfachen Code schreiben kann.

Was Sie hier vermissen, ist Bildung, wir alle lernen noch, einige sind nur weiter als andere. Soweit ich weiß, ist dies kein Wettbewerb, sondern ein Ort des Wissensaustausches und der Unterstützung.

Und übrigens, ich glaube nicht, dass irgendjemand in diesem Forum ein Programm mit einer Million Zeilen schreiben wird.

 
Alain Verleyen:
Du hast den Punkt nicht verstanden, Dirk. Nicht-Spezialisten wollen einfache und klare Code-Beispiele, was in der Tat mein Ziel mit diesem Thema war. Aber das scheint für Spezialisten völlig unverständlich zu sein.

Die neuesten Sprachen versuchen, die Dinge so zu vereinfachen, dass auch Menschen mit geringeren Programmierkenntnissen in die Gruppe der "Programmierer" aufgenommen werden können. Das beste Beispiel ist die Pseudo-Sprache HTML. Und das ist der große Fehler. Als MT5 entwickelt wurde, gaben viele "Neulinge" dem OOP-Stil die Schuld, weil er schwierig war. Aber die Wahrheit ist, dass jeder Job seine Profis hat. Wenn man eine Plattform verbessern will, muss man sie komplexer machen. Mehr Funktionen, mehr Flexibilität. Wenn man Leute ohne Programmierkenntnisse das machen lässt, ist das so, als ob jemand ohne Kenntnisse im Hausbau ein Haus bauen würde. Das wird eine Katastrophe sein.

Die Länge der Projekte hängt vom Programmierer ab. Meine Bibliothek ist mittelgroß für die MQL-Sprache. Andere brauchen nur kleine Bibliotheken für die Erstellung von Tools. In meinem Fall ziehe ich es vor, Zeit mit der Entwicklung von Frameworks zu verbringen, um Zeit zu sparen und die Entwicklung in der Zukunft zu vereinfachen. Wenn Sie komplexe UIs erstellen oder Code für andere Projekte wiederverwenden müssen, ist das der klügere Weg.

 
Juan Fernandez:

Die neuesten Sprachen versuchen, die Dinge so zu vereinfachen, dass auch Menschen mit geringeren Programmierkenntnissen in die Gruppe der "Programmierer" aufgenommen werden können. Das beste Beispiel ist die Pseudo-Sprache HTML. Und das ist der große Fehler. Als MT5 entwickelt wurde, gaben viele "Neulinge" dem OOP-Stil die Schuld, weil er schwierig war. Aber die Wahrheit ist, dass jeder Job seine Profis hat. Wenn man eine Plattform verbessern will, muss man sie komplexer machen. Mehr Funktionen, mehr Flexibilität. Wenn man Leute ohne Programmierkenntnisse das machen lässt, ist das so, als ob jemand ohne Kenntnisse im Hausbau ein Haus bauen würde. Das wird eine Katastrophe sein.

Die Länge der Projekte hängt vom Programmierer ab. Meine Bibliothek ist mittelgroß für die MQL-Sprache. Andere brauchen nur kleine Bibliotheken für die Erstellung von Tools. In meinem Fall ziehe ich es vor, Zeit mit der Entwicklung von Frameworks zu verbringen, um Zeit zu sparen und die Entwicklung in der Zukunft zu vereinfachen. Wenn Sie komplexe UIs erstellen oder Code für andere Projekte wiederverwenden, ist das der klügere Weg.

Die Leute können sich also kein Wissen aneignen?

 

Prozedural vs OOP ist eine nutzlose Debatte, vor 3 Jahren wurde es bereits diskutiert und meine Antwort ist völlig gültig, mehr wurde hier nicht gesagt:

Forum über Handel, automatisierte Handelssysteme und das Testen von Handelsstrategien

Programmierer: Was ist Ihre Präferenz: OOP vs Procedural

Alain Verleyen, 2013.06.11 13:11

In Ihrer Umfrage fehlt eine Option für diejenigen, die nichts bevorzugen. Ich meine, das ist nicht nur eine Frage der Vorliebe, es macht keinen Sinn, OOP für ein kleines Skript oder sogar einen einfachen EA zu verwenden. OOP bedeutet immer zusätzlichen Aufwand und ist nur für komplexe Projekte und die Wiederverwendbarkeit von Code (gleicher Code in mehreren Projekten) von Vorteil. Komplex ist nicht gleichbedeutend mit groß. Wenn jemand ein großes, aber relativ einfaches Projekt hat , bedeutetdas nicht automatisch, dass er OOP verwenden muss .

Sie können das große Potenzial von OOP an dem von Metaquotes entwickelten MQL5-Assistenten sehen , es wäre sehr schwierig, ein solches Tool mit prozeduraler Programmierung zu entwickeln, obwohl es machbarist .

OOP sollte verwendet werden:

  • Bei komplexen Projekten, wie von Doerk und James sehr gut beschrieben.
  • Wenn Sie Ihren Code wiederverwenden wollen.

Von nun an werde ich keine Beiträge mehr akzeptieren, die nicht konkret sind, ohne ein Codebeispiel, das zeigt, warum und wie OOP in den oben genannten Fällen besser eingesetzt werden sollte.

 
Alain Verleyen:

Prozedurale vs. OOP ist eine nutzlose Debatte, vor 3 Jahren wurde sie bereits diskutiert und meine Antwort ist völlig gültig, mehr wurde hier nicht gesagt:

OOP sollte verwendet werden:

  • Bei komplexen Projekten, wie von Doerk und James sehr gut beschrieben.
  • Wenn man seinen Code wiederverwenden will.

Von nun an werde ich keinen Beitrag mehr akzeptieren, der nicht konkret ist, ohne ein Codebeispiel, das zeigt, warum und wie OOP in den oben genannten Fällen besser eingesetzt werden sollte.

Dankeschön
 
Ich lese dieses ganze Thema und finde es interessant, aber ist Maschinencode nicht prozedural? Also Hochsprachen, und OOP eingeschlossen, werden alle am Ende im Compiler in prozeduralen übersetzt, richtig? Wenn alle Sprachen in prozeduralen Maschinencode übersetzt werden, können wir also sagen, dass alles in prozeduralem Code gemacht werden kann, wenn der Programmierer die Fähigkeiten dazu hat, bitte korrigiert mich, wenn ich falsch liege
 
Mrluck07:
Ich lese dieses ganze Thema und finde es interessant, aber ist Maschinencode nicht prozedural? Also Hochsprachen, und OOP eingeschlossen, werden alle am Ende im Compiler in prozeduralen übersetzt, richtig? Wenn alle Sprachen in prozeduralen Maschinencode übersetzt werden, können wir also sagen, dass alles in prozeduralem Code gemacht werden kann, wenn der Programmierer die Fähigkeiten dazu hat, bitte korrigiert mich, wenn ich falsch liege

Theoretisch kann alles in prozeduralem Code gemacht werden. Praktisch ist es nicht.
Ein Ziegelstein besteht aus tausenden von Sandpartikeln, man kann also ein Haus ohne Ziegelsteine bauen, nur aus Sand.
Aber niemand versucht es überhaupt, wenn man Ziegel hat.

Ein Flugzeug wird aus vorgefertigten Teilen gebaut - Flügel, Räder, Sitze, Computer, usw. Am Ende sind sie alle aus Metall oder Plastik oder Glas. Aber niemand wird ein Flugzeug aus reinem Glas, Plastik und Metall bauen.

Zur Debatte im Allgemeinen (als Antwort auf Alain und die anderen): Nehmen Sie das CArrayObj - ein Array von Objekten. Das allein ist schon genug, um zu beantworten, was die Macht von OO ist (die weit mehr ist als das). Es kann ein Array von beliebigen Objekten speichern - wie zum Beispiel Indikatoren.
Und mit geringem Aufwand komplexe Dinge für all diese verschiedenen Indikatoren tun. Und wenn Sie nun eine neue Fähigkeit dazu haben wollen, zum Beispiel wenn Sie wissen wollen, wann ein Indikator-Puffer überschritten wird, müssen Sie nur die Methode in CIndicator einfügen, das war's. Und so weiter. Wie würden Sie das in einem prozeduralen Programm machen?

Und das kann man in allen Bereichen tun - Strategien, Trades, Deals, Signale - was auch immer.

 
Amir Yacoby:

Theoretisch kann alles mit prozeduralem Code gemacht werden. Praktisch ist es nicht.
Ein Ziegelstein besteht aus Tausenden von Sandpartikeln, man kann also ein Haus ohne Ziegelsteine bauen, nur aus Sand.
Aber niemand versucht es überhaupt, wenn man Ziegelsteine hat.

Ein Flugzeug wird aus vorgefertigten Teilen gebaut - Flügel, Räder, Sitze, Computer, usw. Am Ende sind sie alle aus Metall oder Plastik oder Glas. Aber niemand wird ein Flugzeug aus reinem Glas, Plastik und Metall bauen.

Zur Debatte im Allgemeinen (als Antwort auf Alain und die anderen): Nehmen Sie das CArrayObj - ein Array von Objekten. Das allein ist schon genug, um zu beantworten, was die Macht von OO ist (die weit mehr ist als das). Es kann ein Array von beliebigen Objekten speichern - wie zum Beispiel Indikatoren.
Und mit geringem Aufwand komplexe Dinge für all diese verschiedenen Indikatoren tun. Und wenn Sie nun eine neue Fähigkeit dazu haben wollen, zum Beispiel wenn Sie wissen wollen, wann ein Indikator-Puffer überschritten wird, müssen Sie nur die Methode in CIndicator einfügen, das war's. Und so weiter. Wie würden Sie das in einem prozeduralen Programm machen?

Und das kann man in allen Bereichen tun - Strategien, Trades, Deals, Signale - was auch immer.

Dieses Thema war absichtlich provokativ, aber die Antwort auf die Hauptfrage (was kann OOP, was prozeduraler Code nicht kann) ist NICHTS.

OOP ist sicherlich nicht die einzige Möglichkeit, Bausteine zu erstellen und zu verwenden. Es gibt mindestens genauso viele Möglichkeiten, schlechten Code in OOP zu erstellen, wie in prozeduralem Code (und höchstwahrscheinlich mehr). Schauen Sie sich nur die "Standardbibliothek" von Metaquotes an, die in Wirklichkeit alles andere als "Standard" ist.

OOP versus prozedural ist eine nutzlose und endlose Debatte. Eine sinnvollere sollte lauten: "Wie produziert man Qualitätscode? Mit und ohne OOP, mit und ohne prozedural, mit und ohne irgendeinem Programmierparadigma". Wenn Sie ein Holzhaus bauen wollen, brauchen Sie keine Ziegelsteine, aber es muss ein gutes, solides und zuverlässiges Haus sein.

 
Ich weiß, das war provokant, Alain.
Und gutes Programmieren kann sicherlich überall praktiziert werden. Da aber jede Welt aus Objekten aufgebaut ist, auch die Handelswelt, ist oo viel besser geeignet, diese Welt zu beschreiben als Prozeduren. Natürlich nur, wenn sie beide gut geschrieben sind.


 
Amir Yacoby:

Theoretisch kann man alles in der Verfahrenssprache machen. Praktisch ist es nicht.
Ein Ziegelstein besteht aus Tausenden von Sandpartikeln, man kann also ein Haus ohne Ziegelsteine bauen, nur aus Sand.
Aber niemand versucht es überhaupt, wenn man Ziegel hat.

Ein Flugzeug wird aus vorgefertigten Teilen gebaut - Flügel, Räder, Sitze, Computer, usw. Am Ende sind sie alle aus Metall oder Plastik oder Glas. Aber niemand wird ein Flugzeug aus reinem Glas, Plastik und Metall bauen.

Zur Debatte im Allgemeinen (als Antwort auf Alain und die anderen): Nehmen Sie das CArrayObj - ein Array von Objekten. Das allein ist schon genug, um zu beantworten, was die Macht von OO ist (die weit mehr ist als das). Es kann ein Array von beliebigen Objekten speichern - wie zum Beispiel Indikatoren.
Und mit geringem Aufwand komplexe Dinge für all diese verschiedenen Indikatoren tun. Und wenn Sie nun eine neue Fähigkeit dazu haben wollen, zum Beispiel wenn Sie wissen wollen, wann ein Indikator-Puffer überschritten wird, müssen Sie nur die Methode in CIndicator einfügen, das war's. Und so weiter. Wie würden Sie das in einem prozeduralen Programm machen?

Und das kann man in allen Bereichen tun - Strategien, Trades, Deals, Signale - was auch immer.

Wenn Sie in Ihrem Beispiel OO codieren und auf Kompilieren klicken, wird Maschinencode erzeugt. Aber ist dieser Maschinencode nun prozedural oder nicht? Ich kenne die Antwort wirklich nicht, weiß das jemand hier? Wenn Maschinencode prozedural ist, dann kann man OO nur als eine höhere Sprache bezeichnen, die nur die Programmierung erleichtert, aber nichts Besonderes ist, so dass ein erfahrener C-Programmierer die gleiche Arbeit wie ein OO-Programmierer leisten kann, ja sogar besser optimiert sein kann. Also meine Frage, ist Ex-Code prodedural oder nicht?