Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 3
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Allez, je n'avais pas de modèle du tout, puis j'ai commencé avec la procédure, puis je suis passé au modèle objet.
Et en général, par défaut, MQ nous donne un modèle basé sur les événements. On nous donne d'abord les événements par lesquels tout arrive.
On parle de mq5 ?
donc nous parlons de la même chose.
De la brancheappelée "Erreurs, bugs, questions" :
Un problème très typique pour le début de la conception : comment organiser (structurer) la gestion des événements dans un programme de manière à pouvoir le développer et en même temps retravailler le moins possible ce qui a déjà été fait.
Voulez-vous discuter des options ?
De manière générale, il s'agit d'une question plus globale qui ne se limite pas à l'organisation d'un bon modèle d'événement. Cela dépend en grande partie de la langue elle-même. Malheureusement, les moyens linguistiques de MQL5 sont au niveau des années 80 du siècle dernier. Les normes de programmation modernes sont très éloignées des principes de programmation OOP d'origine. Aujourd'hui, la décomposition est préférable à l'héritage, le polymorphisme est assuré par des liens horizontaux non hiérarchiques au niveau de l'interface, et la réutilisation du code est assurée par de riches collections de bibliothèques standard, une conception décomposée et l'inclusion transparente de constructions tierces dans le projet.
Y a-t-il de la littérature par exemple ?
Plus précisément sur ce sujet :
Quelle langue considérez-vous comme un modèle (en termes de modernité et de convivialité) ?
Java/C#
Et il ne s'agit même pas de mon parti pris (bien que je n'en sois pas dépourvu), mais du fait que ces langages sont le produit final d'une longue évolution de la technologie de programmation. Ils ont été créés à notre époque, et se sont basés sur l'expérience de leurs prédécesseurs.
Avant de rédiger un projet de grande envergure, il est bon de mettre en place une infrastructure clairement établie pour soutenir le projet :
Y a-t-il de la littérature par exemple ?
Bien sûr qu'il y en a.
// Mais n'oublions pas que la communication en direct est parfois beaucoup plus efficace pour apprendre que les livres (même les bons).
--
Ce livre a été très utile à une époque (début des années 90) :
B.Liskov, J.Gatag. "Utilisation des abstractions et des spécifications dans le développement de logiciels".
J'y ai appris l'essentiel de la programmation orientée objet, qui n'est pas la possibilité supplémentaire de découper le programme en "cubes" pratiques - ce n'est qu'une commodité supplémentaire. L'essentiel est l'abstraction des données.
Vous pensez de manière orientée objet, je pense de manière fonctionnelle).
1. l'abstraction procédurale (algorithmique) est une caractéristique de la programmation fonctionnelle. l'entité d'abstraction est la procédure (fonction). Il permet de séparer une demande d'exécution d'une action ou d'un calcul de sa mise en œuvre. Le code de la fonction est isolé dans un bloc séparé (procédure, fonction), ce code est référencé via le découplage des paramètres formels/réels (c'est l'essence et la caractéristique principale de l'approche procédurale). Le programme est capable de rester inchangé lorsqu'il est nécessaire de modifier le mode (algorithme) de calcul ou d'action (par exemple, l'écriture dans un fichier).
Mais si un programme doit modifier une structure de données de base (tableaux globaux par exemple), il va devoir réécrire de nombreuses procédures travaillant avec ces données. -- Il s'agit d'une limitation de base du style de programmation procédurale.
2) L'abstraction des données - l'encapsulation des structures de données de base (ainsi que des opérations de base sur celles-ci) dans des entités séparées ("classes"), en respectant la règle de base : ne jamais s'y référer (données encapsulées) directement, mais seulement et exclusivement à travers les fonctions de la même classe, spécifiquement créées pour elles ("interface"). Ainsi, l'abstraction de la forme de stockage des données des moyens de traitement de ces données est réalisée.Et il y a une opportunité sans précédent (dans la programmation procédurale) - développer un programme sans se préoccuper à l'avance des modes de représentation des données. Puisque les données sont accessibles à travers une interface standard immuable, vous pouvez améliorer les modes de représentation des données à n'importe quelle étape du développement du projet, et ce changement n'entraîne pas la nécessité de modifier d'autres parties du projet. Dans la programmation procédurale, c'était impossible - la structure de base des données déterminait strictement les modes de leur traitement.
On m'a également appris à dessiner sur papier, un langage algo simplifié, avant d'écrire le programme, mais je ne m'y suis jamais habitué.
De nos jours, aucun programmeur normal ne dessine de diagrammes de flux. Il s'agit d'un non-sens théorique conçu pour enseigner aux écoliers, mais pas pour travailler sur des projets réels.
Je dessine sur du papier, c'est plus pratique pour moi. Il faut parfois jusqu'à 50 feuilles pour obtenir une structure claire. Vous pouvez, bien sûr, utiliser des éditeurs spéciaux, mais chacun d'entre eux est pour moi inconfortable (limité), impossible de réaliser une envolée, bref ils ralentissent le travail.
Et qu'adviendra-t-il de votre structure claire si, au milieu, ou même vers la fin du projet, le client change soudainement :
Il s'agit d'un bon test pour voir dans quelle mesure votre projet est prêt et résilient au changement. Dans la pratique, vous devez toujours faire face à des modifications des exigences initiales. Il est donc préférable d'abandonner le paradigme "tout prévoir" au profit du paradigme "tâche - solution".