Gespräche über die PLO in der Lounge - Seite 7
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
ZS: Übrigens habe ich in dem ganzen Thread keinen einzigen Wunsch nach einer Berichterstattung über irgendein Thema gesehen, wie üblich, der übliche Groll.
Nach der Wahl des Ausgangsbeispiels zu urteilen, bestehen berechtigte Zweifel an der Qualität der Berichterstattung
Können wir genauer sagen, wer sie sind und was sie nicht gelernt haben? Moderatoren haben nicht gelernt, wie man putzt oder etwas anderes )
ZS: durch die Art und Weise, in der ganzen Thread nicht einen einzigen Wunsch, ein Thema zu decken, wie immer, die üblichen Gerangel zu sehen. Also habe ich beschlossen, Videos auf YouTube aufzuzeichnen, die zeigen, wie OOP funktioniert, zumindest wird es von Nutzen sein. Wie auch immer, nach einer Weile wird der Zweig im branch_sucker landen.
Lassen Sie mich das klarstellen: Sie haben nicht gelernt, wie man OOP benutzt.
Alexey, ich denke, du bist dir selbst bewusst, dass man OOP nicht einfach lernen kann. Es gibt ein formales Wissen über OOP: Vererbung, Kapselung, Polymorphismus - all diese Mantras werden oft wiederholt, aber es schadet mehr als es nützt, wenn jemand sie auswendig lernt und gewaltsam und unangemessen anwendet, wie z. B. eine Expertenklasse, die von einem MM-Modul erbt (hallo an SB-Entwickler:).
Was MQL betrifft - es ist eine sehr schwache Sprache in Bezug auf OOP: Typkontrolle ist völlig abwesend (zumindest haben sie sicheres Casting implementiert), Reflexion steckt in den Kinderschuhen und ist sehr begrenzt, es gibt überhaupt keine Schnittstellen. Es stellt sich die Frage: Welche Art von OOP kann in MQL gelehrt werden? Was soll man sagen, wenn die Entwickler selbst ein solches Durcheinander in der Standardbibliothek anrichten, dass es manchmal einfach nur beängstigend ist.
Um genauer zu sein: Wir haben OOP nicht gelernt.
Alexey, ich denke, Sie sind sich der Tatsache bewusst, dass man OOP nicht einfach so lernen kann. Es gibt ein formales Wissen über OOP: Vererbung, Kapselung, Polymorphismus - all diese Mantras werden oft wiederholt, aber es schadet mehr als es nützt, wenn jemand sie auswendig lernt und gewaltsam und unangemessen anwendet, wie z. B. eine Expertenklasse, die von einem MM-Modul erbt (Hallo an die SB-Entwickler:).
Was MQL betrifft - es ist eine sehr schwache Sprache in Bezug auf OOP: Typkontrolle ist völlig abwesend (zumindest haben sie eine sichere Konvertierung gemacht), Reflexion ist in den Kinderschuhen und sehr begrenzt, es gibt überhaupt keine Schnittstellen. Es stellt sich die Frage: Welche Art von OOP kann in MQL gelehrt werden? Was soll man sagen, wenn Entwickler selbst einen solchen Buckel in der Standardbibliothek formen, dass es manchmal einfach nur beängstigend ist.
Ja, sie ist schwach, aber Projekte von mittlerem Schwierigkeitsgrad können trotzdem durchgeführt werden. SB wurde von verschiedenen Personen mit unterschiedlichem Ausbildungsstand durchgeführt. Und es fehlt das Wesentliche, ich benutze immer noch Ihr CD-Wörterbuch, und es ist der Mast fällig Sache.
Und was jetzt? Sich hinlegen und sterben? )) Vielleicht werden Sie ja doch noch zu dll.
Sie können OOP lernen, denke ich. Ich habe es selbst gelernt. Und das taten auch andere.
Und man kann immer noch OOP lernen, denke ich. Ich habe es selbst gelernt. Und das haben andere auch.
Man muss also von den richtigen Beispielen lernen. Aber es gibt keine in SB. Nehmen Sie zum Beispiel CObject - es bietet keine Typkontrolle, es bietet keine Arbeit mit Objekten auf Schnittstellenebene, aber es enthält sinnlose Methoden wie Save() und Load(), die in der Praxis nie neu definiert werden. Die Zeiger m_prev und m_next werden in einer einzigen CList-Klasse verwendet, sind aber als Ballast für alle ihre Nachfolgeklassen vorhanden. Am nützlichsten ist die Methode Comparer(). In den meisten Fällen wird sie jedoch außer Kraft gesetzt. Da Comparer() eine Schnittstelle ist, sollte sie nicht im CObject, sondern als eigene Klasse definiert werden.
Offensichtlich werden static und const (dies ist nicht OOP) nicht benötigt.
Was OOP betrifft, so ist es sehr interessant, wie die nächste Funktion, die eine breite praktische Anwendung hat (überhaupt nicht abstrakt), im prozeduralen Stil aussehen würde.
Natürlich kann jede OOP im prozeduralen Stil umgeschrieben werden. Aber ich bin an der Praxis interessiert. Also habe ich den obigen kleinen Code genommen, bei dem OOP auch auf ein Minimum reduziert ist.
Wie viel schöner/bequemer/lesbarer/korrekter ist also der prozedurale Stil im Vergleich zu OOP in diesem Beispiel? Nun, nicht, um ein paar Seiten lang zu reden, sondern nur, um kurzen Quellcode prozedural vs. OOP zu vergleichen. Ich fordere die OOP-Gegner auf, eine Meisterklasse zu zeigen. Dies ist nicht der gefürchtete MT5, sondern der gute alte MT4.
Wie lernt man auf dieselbe Art und Weise zu programmieren? :) es sieht sehr schön aus.
Oder vielleicht müssen Sie Ihre Einstellung ändern.
Ich wusste zum Beispiel nicht, dass Strukturen fast genauso verwendet werden können wie Klassen, nämlich mit einem Konstruktor
Ich wusste zum Beispiel nicht, dass Strukturen fast genauso wie Klassen verwendet werden können, mit einem Konstruktor
Welche Formen können Sie auf genau dieselbe Weise programmieren lernen? :) es sieht sehr schön aus
oder vielleicht müssen Sie auch Ihre Einstellung ändern.
Ich wusste zum Beispiel nicht, dass Strukturen fast wie Klassen verwendet werden können, mit einem Konstruktor
Und darf ich fragen: Welche Genialität sehen Sie im Code von fxsaber? Vielleicht sind es die Nebeneffekte von IsChange, die Sie fasziniert haben, oder die Idee, dass der Systemzustand auf der Benutzerebene dupliziert werden muss?
Darf ich fragen: Welche Genialität sehen Sie in den Codes von fxsaber? Vielleicht sind es die Nebeneffekte von IsChange, die Sie faszinieren, oder die Idee, dass der Systemzustand auf Benutzerebene dupliziert werden sollte?
Wahrscheinlich, weil ich diesen Code kaum verstehe :)
Tut mir leid, ich bin ein Amateurprogrammierer... Ich kenne mich mit OOP nur in den Grundzügen aus.
In C++ sind Klasse und Struktur gleich, nur einige Standardwerte sind anders.
Das ist cool, das wusste ich nicht... Ich schätze, ich muss einfach die Profis besser kennenlernen.
Man muss also von den richtigen Beispielen lernen. Und es gibt keine in SB. Nehmen Sie zum Beispiel CObject - es bietet keine Typkontrolle, es bietet keine Arbeit mit Objekten auf Schnittstellenebene, aber es enthält sinnlose Methoden wie Save() und Load(), die in der Praxis nie neu definiert werden. Die Zeiger m_prev und m_next werden in einer einzigen CList-Klasse verwendet, sind aber als Ballast für alle ihre Nachfolgeklassen vorhanden. Am nützlichsten ist die Methode Comparer(). In den meisten Fällen wird sie jedoch außer Kraft gesetzt. Da Comparer() eine Schnittstelle ist, sollte sie nicht im CObject, sondern als eigene Klasse definiert werden.