Strukturregeln. Lernen, wie man Programme strukturiert, Erforschung von Möglichkeiten, Fehlern, Lösungen usw. - Seite 3
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
Komm schon, ich hatte überhaupt kein Modell, dann habe ich mit Prozeduren angefangen und bin dann zum Objektmodell übergegangen.
Und im Allgemeinen gibt uns MQ standardmäßig ein ereignisbasiertes Modell. Zunächst werden uns die Ereignisse mitgeteilt, durch die alles geschieht.
Reden wir über mq5?
Wir reden also über dieselbe Sache.
Aus dem Zweig"Fehler, Bugs, Fragen":
Ein sehr typisches Problem für den Beginn des Entwurfs: Wie kann man die Ereignisbehandlung in einem Programm so organisieren (strukturieren), dass es (das Programm) weiterentwickelt werden kann und gleichzeitig die Nacharbeit an dem, was bereits getan wurde, minimal ist.
Möchten Sie die Optionen besprechen?
Im Allgemeinen handelt es sich um ein globales Problem, bei dem es nicht nur darum geht, ein gutes Veranstaltungsmodell zu organisieren. Vieles hängt von der Sprache selbst ab. Leider befinden sich die sprachlichen Mittel von MQL5 auf dem Niveau der 80er Jahre des letzten Jahrhunderts. Moderne Programmierstandards sind weit von den ursprünglichen OOP-Programmierprinzipien entfernt. Heute ist Dekomposition der Vererbung vorzuziehen, Polymorphismus wird durch horizontale, nicht-hierarchische Verknüpfungen auf Schnittstellenebene gewährleistet, und die Wiederverwendung von Code wird durch umfangreiche Sammlungen von Standardbibliotheken, dekomponiertes Design und die transparente Einbeziehung von Builds Dritter in das Projekt sichergestellt.
Gibt es zum Beispiel Literatur?
Speziell zu diesem Thema:
Welche Sprache ist für Sie ein Vorbild (in Bezug auf Modernität und Benutzerfreundlichkeit)?
Java/C#
Und es geht nicht einmal um meine Voreingenommenheit (obwohl ich nicht ohne sie bin), sondern darum, dass diese Sprachen das Endprodukt einer langen Entwicklung in der Programmiertechnik sind. Sie wurden in unserer Zeit geschaffen und beruhen auf den Erfahrungen ihrer Vorgänger.
Bevor ein großes Projekt geschrieben wird, ist es eine gute Idee, eine klare Infrastruktur zur Unterstützung des Projekts zu schaffen:
Gibt es zum Beispiel Literatur?
Natürlich gibt es das.
// Zur Literatur: Lassen Sie uns literarische Quellen austauschen, aber vergessen wir nicht, dass Live-Kommunikation manchmal viel (um Größenordnungen) effektiver für das Lernen ist als Bücher (selbst gute).
--
Das Buch war zu einer Zeit (Anfang der 90er Jahre) sehr hilfreich:
B. Liskov, J. Gatag. "Verwendung von Abstraktionen und Spezifikationen in der Softwareentwicklung".
Daraus habe ich gelernt, dass der Hauptpunkt der objektorientierten Programmierung nicht die zusätzliche Möglichkeit ist, das Programm in bequeme "Würfel" zu zerlegen - das ist nur eine zusätzliche, begleitende Bequemlichkeit. Der Hauptpunkt ist die Datenabstraktion.
Sie denken objektorientiert, ich denke funktional)
1. Die prozedurale (algorithmische) Abstraktion ist ein Merkmal der funktionalen Programmierung. Die abstrahierende Einheit ist die Prozedur (Funktion). Sie ermöglicht es, eine Anfrage zur Durchführung einer Aktion oder Berechnung von ihrer Umsetzung zu trennen. Der Funktionscode wird in einem separaten Block (Prozedur, Funktion) isoliert, auf diesen Code wird durch Entkopplung von formalen/aktuellen Parametern Bezug genommen (dies ist das Wesen und Hauptmerkmal des prozeduralen Ansatzes). Das Programm ist in der Lage, unverändert zu bleiben, wenn es notwendig ist, die Art und Weise (den Algorithmus) der Berechnung oder der Aktion (z.B. das Schreiben in eine Datei) zu ändern.
Wenn ein Programm jedoch eine grundlegende Datenstruktur ändern muss (z. B. globale Arrays), muss es viele Prozeduren, die mit diesen Daten arbeiten, neu schreiben. -- Dies ist eine grundlegende Einschränkung des prozeduralen Programmierstils.
2) Datenabstraktion - Kapselung der grundlegenden Datenstrukturen (zusammen mit den grundlegenden Operationen auf ihnen) in separaten Einheiten ("Klassen") unter Einhaltung der Grundregel, dass man sich niemals direkt auf sie (die gekapselten Daten) beziehen darf, sondern nur und ausschließlich über die speziell für sie geschaffenen Funktionen derselben Klasse ("Schnittstelle"). Auf diese Weise wird die Abstraktion der Form der Datenspeicherung von der Art und Weise der Handhabung dieser Daten erreicht.Und es gibt eine noch nie dagewesene Möglichkeit (in der prozeduralen Programmierung) - ein Programm zu entwickeln, ohne sich im Voraus Gedanken über die Art und Weise der Datendarstellung zu machen. Da der Zugriff auf die Daten über eine unveränderliche Standardschnittstelle erfolgt, können Sie die Art und Weise der Datendarstellung in jeder Phase der Projektentwicklung verbessern, und diese Änderung zieht nicht die Notwendigkeit nach sich, andere Teile des Projekts zu ändern. In der prozeduralen Programmierung war dies unmöglich - die grundlegende Datenstruktur bestimmte streng die Art und Weise ihrer Verarbeitung.
Ich habe auch gelernt, auf Papier zu skizzieren, eine vereinfachte Algo-Sprache, bevor ich das Programm schrieb, aber ich habe mich nie daran gewöhnt.
Heutzutage zeichnet kein normaler Programmierer mehr Flussdiagramme. Das ist alles theoretischer Unsinn, der für den Unterricht von Schülern gedacht ist, aber nicht für die Arbeit in realen Projekten.
Ich zeichne auf Papier, das ist für mich bequemer, manchmal brauche ich bis zu 50 Blätter, bis sich eine klare Struktur herausbildet. Man kann natürlich spezielle Editoren verwenden, aber jeder von ihnen ist für mich unbequem (begrenzt), unmöglich, einen Höhenflug zu realisieren, kurz gesagt, sie verlangsamen die Arbeit.
Und was passiert mit Ihrer klaren Struktur, wenn sich der Kunde in der Mitte oder sogar gegen Ende des Projekts plötzlich ändert?
Dies ist ein guter Test, um festzustellen, wie bereit und belastbar Ihr Projekt gegenüber Veränderungen ist. In der Praxis muss man immer mit Änderungen der ursprünglichen Anforderungen rechnen. Es ist daher besser, vom Paradigma "Für alles sorgen" ganz wegzukommen und zum Paradigma "Aufgabe - Lösung" überzugehen.