Mein Ansatz. Der Kern ist der Motor. - Seite 18
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
Nein, während wir über Casual Programming diskutieren, ziehe ich die Decke zu OOP, der Themenstarter hält immer noch daran fest! Er schreibt, dass man alles im Kopf behalten kann - na ja, Casual Programming)))
Core-Engine
Gelegenheits-Programmierung )))
Gelegenheits-Programmierung :)
Gelegenheits-Programmierung :)
Vielleicht haben Sie Recht, ich erinnere mich an den Begriff - vor ein paar Monaten auf einem anderen Forum Kerl nannte sich ein Casual Programmierer, ich habe sogar versucht zu klären, was es bedeuten könnte, mein Wissen über das Wort casual ist nur mit Android-Spiel verbunden - "Zuma", es stellte sich heraus, dass es ein Programmierer, der zufällig programmiert ist - von Gelegenheit zu Gelegenheit ))))
OOP ist eine sehr flexible Methodik, die keine apriorischen Vorstellungen wie das Konzept des "Kernels" hat. Das Kernel-Modell, um das es hier geht, kann jedoch sehr wohl mit OOP erstellt werden. Die Aussage ist also nicht ganz richtig.
Nein, OOP hat damit überhaupt nichts zu tun. Der Kernel ist Unix, wir bauen alles um den Kernel herum auf; die Shell ist alles, was wie Windows ist, wir entfernen das Überflüssige und arbeiten mit dem Rest. Im Allgemeinen geht es hier um ein Betriebssystem.
Cajun-Programmierung :)
Cajual, mach dir keine Sorgen.
Was mich an OOP abstößt, ist das starre Format, in dem Code geschrieben wird. Wie Sie gesehen haben, neige ich dazu, große Datentabellen zu erstellen und finde das sehr praktisch. Bei OOP muss ich mich an eine Reihe von Regeln halten, was ich persönlich sehr einschränkend finde.
Kurz gesagt, ich programmiere mit einer anderen OOP. Meine eigene. Es gibt nur wenige Regeln und viel Freiheit. Die Funktionalität selbst ist in großen Blöcken gestapelt, und die Daten sind in Kernels organisiert. Ich denke nicht einmal besonders über ihre Struktur nach. Alles entwickelt sich von selbst. Auf der intuitiven Ebene.Peter, diese Regeln sind die, die Sie selbst brauchen. Deshalb "versteifen" sie dich. Damit Sie nicht aus Versehen in etwas hineingeraten, was Sie nicht sollen. Der OOP-Stil ist in der Tat eine "Verkehrsregel" - natürlich schränken sie den Fahrer ein. Und in einem Dorf mit drei Höfen schaut niemand auf sie, es ist einfacher und schneller (effizienter). In einer Großstadt ist es jedoch genau umgekehrt: Die Verkehrsregeln ermöglichen die effizientesten Verkehrsverbindungen. So ist es auch mit dem AOP. Sie sind die Regeln, die es Ihnen ermöglichen, große, komplexe Systeme auf die effizienteste Weise aufzubauen.
In Ihrem System hat sich einfach noch nichts geändert, es wird nur in sehr begrenztem Umfang genutzt und muss nicht geändert werden. Deshalb können Sie es in Ihrem Kopf behalten. Es ist in Ordnung, wenn das System Benutzer bekommt und Änderungen benötigt - der Mangel an Kontrolle und Kapselung wird ziemlich stressig sein.
Alles andere - kein Unterschied, OOP und Ihr Stil (wie gesagt, Sie haben auch einen prozeduralen Stil - leidet auch unter den gleichen Mängeln - globale Variablen, fehlende Typkontrolle, und so weiter) sind ansonsten ähnlich.
Zur Verteidigung Ihres Stils müssen Sie nur eines beweisen - dass es besser ist, das gesamte System in einem riesigen globalen Array mit beliebigem Zugriff zu halten, als das Programm in einen Haufen kleiner Teile zu zerlegen, die in Vererbungsketten mit polymorphem Zugriff verschachtelt und durch Kapselung verborgen sind.
Übrigens gibt es in diesem Forum auch Leute, die das Erben nicht mögen - ich denke, sie könnten Sie unterstützen.
Ein weiterer Vorteil der OOP-Methode im Gegensatz zur Methode von Peter. In der OOP benötigt der Programmierer den Quellcode der Basisklasse nicht und muss auch nicht verstehen, wie sie funktioniert. Um die Funktionalität der Basisklasse zu erweitern oder zu ändern, genügt es, einen Erben dieser Klasse zu erstellen.
Wenn Sie die Methode von Peter verwenden, muss der Programmierer den gesamten langen Code verstehen, und wenn es keinen Quellcode gibt, müssen Sie ihn neu schreiben.
Alles andere - kein Unterschied, OOP und Ihr Stil (wie bereits erwähnt, haben Sie einen prozeduralen Stil - leidet auch unter den gleichen Nachteilen - globale Variablen, fehlende Typkontrolle, und so weiter) sind ansonsten ähnlich.
ich könnte falsch sein, und googeln ist zu faul, aber der prozedurale Stil impliziert eine logische Vollständigkeit einer Prozedur (Funktion) - "abschrauben" es aus der Quelle und verwenden Sie es in anderen Code, dh die eingebauten MQL-Funktionen nehmen Daten als Parameter und geben das Ergebnis.... und hier ist Piotr auf beide Füße gefallen )))) - Der Austausch über global deklarierte Variablen reduziert die Portabilität des Codes und ermöglicht schwer zu verfolgende Bugs ;)
Also gut. Sagen wir, ich bin überzeugt.
Im Prinzip habe ich das alles schon lange verstanden. Und ich stimme ihr zu. Gleichzeitig bevorzuge ich aber auch meinen eigenen Ansatz. Warum?
Dafür gibt es einen besonderen Grund:
PROGRAMMENTWICKLUNG.
//---------------------------------------
Wie schnell wird sich das Programm mit OOP und mit meinem Ansatz entwickeln? Welcher Ansatz ist günstiger für das Wachstum und die Komplikation der Mechanismen?
Ich bin zu dem Schluss gekommen, dass mein Ansatz + Muttersprache im Code (60 % Russisch und 40 % Englisch), ein maximal schnelles Wachstum des Programms ergeben.
Genau dieses schnelle Wachstum ist es, was ich brauche. Nicht in die Details gehen. Nicht nur die einzelnen Codezeilen zu überfliegen. Das ist kein professioneller Ansatz.
Ich wollte, dass sich das Programm schnell entwickelt und komplexer wird. Es sollen Mechanismen geschaffen werden, die die ihnen zugewiesenen Aufgaben erfüllen. Schnell und einfach.
So können Sie mit ein paar Zeilen Code neue Funktionen hinzufügen.
Mein Ansatz ist der OOP bei der Lösung dieser speziellen Aufgabe überlegen.