Mon approche. Le noyau est le moteur. - page 14
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
Le format est simple, mais ça ne marche pas avec lui. Je veux dire quand il y a beaucoup de propriétés dans les objets.
Voici un exemple de votre approche, réellement utilisée, les principes sont les mêmes. L'analyse lexicale du texte, il est très difficile de faire quelque chose manuellement. Seulement l'automatisation. Et ne dites pas que c'est pratique.
Le tableau de prototypes affiché est le résultat de l'initialisation manuelle des propriétés de l'objet avec des valeurs par défaut. Il n'est vu que par le développeur.
Noyau principal - est compilé automatiquement à partir des prototypes d'éléments. Ensuite, les prototypes sont convertis en éléments concrets. Aussi automatiquement.
Quant au travail avec le constructeur, il existe des mots-clés simples et une forme de dessin pratique. Il n'y a pas de telles tables là-bas.
Voici un autre exemple qui correspond à votre idée, avec juste beaucoup d'éléments dynamiques. Il existe des stratégies entières, trois dans l'exemple. Il n'y a pas beaucoup de commodités ici. Dans le fichier joint.
En d'autres termes, afin de maintenir la dimensionnalité du tableau, certains de vos objets ont des propriétés fictives. C'est très souple, on ne peut rien dire.
Hélas, nous devons nous accommoder temporairement de ce désagrément. D'autre part, un noyau bidimensionnel permet un accès extrêmement pratique et rapide, l'intégration de boucles et bien plus encore. Si vous faites un noyau unidimensionnel, il n'y aura pas de "fausses" propriétés. Mais la commodité sera bien moindre. Ou bien, vous pouvez simplement placer les propriétés du texte et de l'icône dans un certain nombre de propriétés Core. Et le problème sera éliminé. Je le ferai à l'avenir.
Voici un autre exemple qui correspond à votre idée, avec juste beaucoup d'éléments dynamiques. Il existe des stratégies entières, trois dans l'exemple. Il n'y a pas beaucoup de commodités ici. Dans le fichier joint.
J'ai d'abord prévenu les lecteurs que mon approche ne vise pas à faciliter la tâche d'un programmeur. Je vous propose la conception du développement le plus puissant et le plus rapide d'un programme.
Bien sûr, ils diront que le développement le plus rapide d'un programme est de brancher des blocs prêts à l'emploi. Oui, mais la qualité du programme diminue et les frais généraux augmentent. La jonction des blocs n'est pas la meilleure solution en termes d'efficacité.
J'ai d'abord prévenu les lecteurs que mon approche n'était pas axée sur la convivialité pour les programmeurs. Il offre le concept du développement le plus puissant et le plus rapide d'un programme.
Elle est pratique lorsque le programmeur ne modifie/crée pas directement ces données.
L'utilisation d'un code qui fonctionne avec de telles données est très pratique.
J'ai d'abord prévenu les lecteurs que mon approche n'était pas axée sur la convivialité pour les programmeurs. Il offre le concept du développement de programmes le plus puissant et le plus rapide.
Comment ces deux points peuvent-ils coexister : manque de commodité pour le programmeur et développement rapide des programmes ? Comment développer un programme rapidement, s'il n'est pas pratique de le faire ?
Quel est le problème du contrôle ? Ajoutez une propriété, et augmentez la taille des rangées du noyau. C'est tout.
Et que ferez-vous s'il s'avère nécessaire de faire un bouton non pas rectangulaire, mais circulaire ou triangulaire ?
Si vous utilisez la POO, vous créerez une classe de base Button, qui possède une méthode abstraite Draf et qui est responsable du dessin des boutons. Pour un bouton rond, vous devrez créer un héritier de Button, qui suffira à surcharger la méthode Draf, qui implémentera le dessin du bouton rond. Pour un bouton rectangulaire, il suffira également de créer un héritier de Button et de surcharger la méthode Draf pour dessiner un bouton rectangulaire.
A quoi cela ressemblerait-il si vous utilisiez votre méthode ?
Voici un autre exemple qui correspond à votre idée, avec juste beaucoup d'éléments dynamiques. Il existe des stratégies entières, trois dans l'exemple. Il n'y a pas beaucoup de commodités ici. Dans le fichier joint.
Pas question !
C'est une belle chose... c'est un automate empilable.
avec une connaissance minimale de l'assembleur et de Forth, c'est un jeu d'enfant à lire. S'il y avait des commentaires, ce ne serait pas plus compliqué que MQL.
C'est pratique lorsque le programmeur ne modifie/crée pas directement ces données.
L'utilisation d'un code qui fonctionne avec de telles données est très pratique.
Vous verrez, un tableau de prototypes est créé une fois. Et puis, il est changé TRÈS rarement. Seulement en cas de modifications importantes du programme.
Pas question !
C'est une belle chose... une machine à pile claire.
Si vous connaissez l'assembleur et le Forth le moins possible, il se lit en un clin d'œil. S'il y avait des commentaires, ce ne serait pas plus compliqué que MQL.
C'est un gadget cool.) Vous êtes d'accord, il est plus facile d'écrire des programmes en MQL qu'en assembleur. Je parle de convivialité, d'efficacité.