Programmation OOP vs programmation procédurale - 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
Pouvez-vous me donner un exemple de ces tâches de type unique, qu'il vaut mieux ne pas faire sans la POO ?
Sans POO vous pouvez le résoudre, mais avec la POO c'est plus rapide, je vous l'ai dit...
Par exemple, un modèle peut contenir de 0 à 100 modèles de chandeliers, de 0 à 30 indicateurs différents et de 1 à 5 signaux différents dans chacun d'eux... Donc, nous avons une classe, et nous pouvons définir avec le constructeur que la première instance contiendra 23 modèles de ce type et 2 indicateurs avec 1 signal chacun... La seconde instance contiendra 12 autres modèles et 8 autres indicateurs... Ensuite, nous posons la condition que les deux instances doivent donner un signal d'ouverture à une distance maximale de 4 barres l'une de l'autre ...
Tout cela se fait en 5 secondes si les signaux des modèles et tout le reste sont décrits dans le cours... Et il peut y avoir autant de combinaisons de tout cela que vous le souhaitez, et même sans client, il suffit d'optimiser tout cela automatiquement dans l'optimiseur et de rechercher des conditions d'entrée favorables.... L'optimiseur peut élargir le nombre d'instances et les propriétés de chacune d'entre elles... enfin, etc. ;)
Ce n'est pas l'argument principal.
Il n'existe pas d'analogue du polymorphisme dans la programmation procédurale.
Il est étrange que durant toute ma pratique, puisque j'étais un novice complet en programmation et que je le suis toujours dans une certaine mesure, je n'ai jamais trouvé nécessaire d'utiliser le polymorphisme... Cela doit être mon destin.
(L'enfer sait pourquoi...))
Sans POO vous pouvez le résoudre, mais avec la POO c'est plus rapide, je vous l'ai dit...
Par exemple, un modèle peut contenir de 0 à 100 modèles de chandeliers, de 0 à 30 indicateurs différents et de 1 à 5 signaux différents dans chacun d'eux... Ainsi, nous avons une classe, et nous pouvons définir avec le constructeur que la première instance contiendra 23 modèles de ce type et 2 indicateurs avec 1 signal chacun... La deuxième instance contiendra 12 autres modèles et 8 autres indicateurs... Ensuite, nous posons la condition que les deux instances doivent donner un signal d'ouverture à une distance maximale de 4 barres l'une de l'autre ...
Tout cela se fait en 5 secondes si les signaux des modèles et tout le reste sont décrits dans le cours... Et il peut y avoir autant de combinaisons de tout cela que vous le souhaitez, et même sans client, il suffit d'optimiser tout cela automatiquement dans l'optimiseur et de rechercher des conditions d'entrée favorables.... L'optimiseur peut élargir le nombre d'instances et les propriétés de chacune d'entre elles... etc. ;))
Toute cette débâcle du GOP est à l'échelle universelle.
Après tout, il faut avoir beaucoup de talent pour pousser un tel projet dans le monde entier.
Et rien n'arrête les apologistes.
Si vous prenez des apologistes locaux. Le manuel du langage MQL se trouve juste sous leur nez. Examinons les sections. Seules trois sections sont consacrées aux données et tout le reste décrit les ACTIONS : programme, opérations sur les tableaux, conversions de données......
Se pourrait-il qu'il s'agisse d'une langue μl qui ne se conforme pas aux " idées de pointe " ?
Prenez un système logiciel beaucoup plus important : R.
Il contient plus de 10 000 paquets, chacun contenant des fonctions - ce sont des actions, pas des objets.
Comme je le vois, tous ces apologistes de la POO d'origine locale et mondiale ne comprennent RIEN à la programmation, à savoir : la valeur (sémantique) de toute donnée est une fonction, une action qui traite ces données. Ils ont écrit int. La signification de ces caractères est déterminée par un ensemble de commandes du processeur, qui sait comment effectuer l'ACTION avec cette variable.
Ensuite, passons aux classes.
Si nous prenons R, pour lequel les classes font partie de la langue.
Une fonction entre un objet d'une certaine classe - la sortie est un objet d'une autre classe généralement. La signification des champs d'entrée-sortie est déterminée uniquement par la fonction qui gère le tout. Et si la fonction n'accepte pas une certaine classe, cette classe n'est d'aucune utilité pour cette fonction. C'est pourquoi la documentation de chaque paquet est exactement la même que celle de µl : les actions et les fonctions sont listées. Les liens entre les fonctions d'un paquetage, ou avec les fonctions d'un autre paquetage, sont déterminés par le nom de la classe avec laquelle la fonction particulière travaille.
Encore une fois. En R, les objets peuvent avoir une complexité arbitraire et peuvent même être très complexes. Mais la valeur de chaque champ d'un objet d'une certaine classe est entièrement déterminée par la fonction qui génère cet objet.
C'est particulièrement évident pour ceux qui écrivent des compilateurs (ce que j'ai fait). Une séquence de code est écrite. Que fait ce code ? Quelle est la signification de ce code ? La signification du texte dans le langage source de tout langage de programmation sera déterminée par le code exécutable que le compilateur crée, qui sera finalement perçu par le processeur. Le compilateur d'une langue trouvera la signification des lignes écrites, mais pas celui d'une autre, c'est-à-dire que les lignes écrites n'ont aucune signification pour cette autre langue.
D'où : la signification d'un objet est toujours une fonction, une action qui est capable de prendre des données d'entrée comme guide d'action, et de générer en sortie une certaine liste de champs, la valeur étant déterminée uniquement par cette fonction.
Konov a essayé d'expliquer ci-dessus que nous devons partir des ACTIONS. Il est nécessaire de traiter des actions, et les objets reliant ces actions seront traités plus tard, lorsque les actions seront définies. Mais la clarté et l'efficacité du code proviennent uniquement de la façon dont nous avons réussi à organiser toute la hiérarchie des ACTIONS et de leur interaction.
Les partisans de la POO disent : créons des objets. Mais quel est le sens des champs d'objets si nous ne définissons pas d'actions sur ces champs ?
Comment le modèle qui contient des modèles est-il mis en œuvre ? Est-ce une fonction, un tableau ou autre chose ? Comment sont rédigés les modèles eux-mêmes ?
oui ils sont généralement décrits, ce n'est pas la question...
Un autre exemple... une classe est comme une bibliothèque avec des livres, et une copie est un chariot... Sur un chariot, vous pouvez mettre les livres de votre choix de la bibliothèque... ... et chercher quelque chose de plus rentable...) Une bibliothèque et un chariot peuvent être faits sans POO, et quand nous parlons d'un grand nombre de chariots, il est préférable de le faire avec POO...
C'est le seul argument en faveur de la POO dans le développement que j'accepte maintenant.
Tu ne devrais pas l'accepter.
La dernière équipe dans laquelle j'ai travaillé comptait environ 300 personnes. La charge de travail totale pour l'ensemble du projet de programme est d'environ 1500 années-hommes. Organiser une telle équipe pour qu'elle travaille ensemble n'aidera en rien l'OOP. Pour cela, il existait d'autres approches, impliquant la décomposition de l'ensemble du problème en étapes et la réglementation minutieuse de tout et de tous à chaque étape. Il y avait des GOST qui le décrivaient. En programmation, il s'agissait de l'USSD (Unified System of Program Documentation). En termes de main-d'œuvre, le codage lui-même a représenté environ 20 % de la main-d'œuvre.
N'écoutez pas les partisans de la POO. Vous êtes sur la bonne voie. Même le fait que vous ne fusionnez pas deux variables en une seule structure - vous ne voyez pas le bénéfice d'une telle fusion.
Un autre exemple plus simple, qui est à la surface même... Générateur d'EA dans MetaEditor... N'importe qui, même s'il ne sait pas programmer, peut bricoler un EA contenant un grand nombre d'indicateurs et de conditions en 10 secondes. )))) Et tout cela est OOP ;)))
Ne parlons pas du générateur, car j'ai décidé de ne pas jurer pendant 2 mois ;)))
Camarades développeurs MQ, j'ai beaucoup de respect pour vous. Je le pense vraiment.
Et je comprends les raisons de la création de ces constructeurs. Je comprends aussi pourquoi tous ces constructeurs pètent dans le vide.
Oui, il peut être considéré comme une sorte d'exemple pour étudier MQL5, mais en aucun cas comme un point de départ pour un véritable robot de trading.
Tu ne devrais pas l'accepter.
La dernière équipe dans laquelle j'ai travaillé comptait environ 300 personnes. La charge de travail totale pour l'ensemble du projet de programme est d'environ 1500 années-hommes. Organiser une telle équipe pour travailler ensemble n'aidera aucunement l'AOP. Pour cela, il existait d'autres approches, impliquant la décomposition de l'ensemble du problème en étapes et la réglementation minutieuse de tout et de tous à chaque étape. Il y avait des GOST qui le décrivaient. En programmation, il s'agissait de l'USSD (Unified System of Program Documentation). En termes d'intensité de main-d'œuvre, le codage lui-même a nécessité environ 20 % de la main-d'œuvre.
N'écoutez pas les partisans de la POO. Vous êtes sur la bonne voie. Même le fait de ne pas fusionner deux variables en une seule structure n'apporte pas grand-chose...
San-Sanych, j'ai récemment été contacté par un soi-disant progager qui a même réussi à vendre quelque chose sur le marché.
Il m'a dit que j'ai essayé de coller des programmes et que j'ai eu une erreur de compilation, alors il m'a envoyé sa colle. Il a promis de me payer.
J'ai jeté un coup d'oeil et je suis malade, 59 erreurs de compilation.
Beaucoup de variables globales comme n,c,m.
Tous en conflit les uns avec les autres.
Et le gars est sûr qu'il a juste besoin de quelques retouches et qu'il peut le lancer sur le marché.
...
Comme je le vois, tous ces apologistes de la POO d'origine locale et mondiale ne comprennent rien à la programmation, à savoir : la valeur (sémantique) de toute donnée est une fonction, une action, qui traite cette donnée. Ils ont écrit int. La signification de ces caractères est déterminée par un ensemble de commandes du processeur, qui sait comment effectuer une ACTION sur cette variable.
...
en mémoire
Tu ne devrais pas l'accepter.
La dernière équipe dans laquelle j'ai travaillé comptait environ 300 personnes. La charge de travail totale pour l'ensemble du projet de programme est d'environ 1500 années-hommes. Organiser une telle équipe pour qu'elle travaille ensemble n'aidera en rien l'OOP. Pour cela, il existait d'autres approches, impliquant la décomposition de l'ensemble du problème en étapes et la réglementation minutieuse de tout et de tous à chaque étape. Il y avait des GOST qui le décrivaient. En programmation, il s'agissait de l'USSD (Unified System of Program Documentation). En termes d'intensité de main-d'œuvre, le codage lui-même a nécessité environ 20 % de la main-d'œuvre.
N'écoutez pas les partisans de la POO. Vous êtes sur la bonne voie. Même le fait de ne pas fusionner deux variables en une seule structure n'apporte aucun bénéfice.
De tels programmes sont maintenant écrits par une personne en trois jours.