Mon approche. Le noyau est le moteur. - page 17
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
Cette approche n'est pas sans rappeler la TurboVision de Pascal. Bien que le contrôle des types et les contraintes d'encapsulation aient déjà été mis en œuvre dans cette bibliothèque.
Je me suis souvenu de Pascal pour l'avoir vu et j'ai même réussi à brancher TurboVision quelques fois pendant les cours... mes souvenirs sont très désagréables, peu importe comment j'ai tordu Turbowijn - de toute façon, le seul résultat était Norton Commander - tout était très étroitement spécialisé, si je ne me trompe pas, Pascal 6.0 n'était pas encore OOP.
Je me souvenais de Pascal parce que je l'avais vu et j'ai même réussi à brancher Turbowijn quelques fois pendant les cours... Les souvenirs sont très désagréables, peu importe comment je tordais Turbowizhne - vous ne pouviez obtenir que Norton Commander en sortie - tout était très spécialisé, si je ne me trompe pas, il n'y avait pas encore de POO dans Pascal 6.0
Si je me souviens bien, TurboVision était précisément la première bibliothèque OOP (avec un support incomplet de l'idéologie de l'époque, mais quand même), et elle est apparue dans Pascal 6.0.
J'ai consultéWikipédia, qui semble être d'accord avec moi.
Si je me souviens bien, TurboVision était exactement la première bibliothèque OOP (avec un support incomplet de l'idéologie de l'époque, mais quand même), et elle est apparue dans Pascal 6.0.
J'ai regardé dansWikipedia. Ça semble être d'accord avec moi.
Hélas, j'ai réussi à passer ce moment dans mon éducation - la POO n'était présentée qu'en C++ ; 5 ans plus tard, je suis passé à Delphi de mon propre chef, le Pascal restant dans mon esprit comme un langage de programmation procédural.
Si je me souviens bien, TurboVision a été la première bibliothèque OOP (avec un support incomplet de l'idéologie de l'époque, mais quand même), et elle est apparue dans Pascal 6.0.
J'ai regardé surWikipedia. Ça semble être d'accord avec moi.
Une POO à part entière pour Pascal est d'abord apparue dans Delphi. Turbo Vision faisait exclusivement référence à l'interface graphique textuelle sous Ms-DOS.
La POO complète pour Pascal est apparue pour la première fois dans Delphi. Turbo Vision s'occupait exclusivement de l'interface graphique textuelle sous Ms-DOS.
Eh bien, c'est ce que je dis - "avec un soutien incomplet". Le sixième Pascal était "Pascal avec des objets". Et c'est vrai, TurboVision était une interface purement fenêtrée. Eh bien, à peu près ce que Peter porte à votre attention.
En fait, la création de Pierre est assez intéressante. C'est l'applicabilité qui soulève des questions. Pas une seule fois je n'ai rencontré que l'absence d'objets accessibles globalement et l'encapsulation complète du code, le fait de travailler exclusivement par le biais d'interfaces purement virtuelles a permis d'éviter beaucoup de bugs, et a aidé à la prise en charge et à la correction des bugs. En fait, Peter a correctement noté - "basé sur la commodité du programmeur".
L'accès complet à un tableau de toutes les fonctionnalités - en théorie, il vous permet réellement d'atteindre une plus grande efficacité, en raison de l'absence de surcharge sur les wrappers d'interface, sur le contrôle et la conversion de type, sur le suivi des protocoles d'accès aux objets.... Cependant, tout cela est possible grâce au fait que le programmeur lui-même doit se souvenir de toutes ces choses et en tenir compte.
Il s'avère que nous prenons sur nous, au lieu de transférer le travail à l'ordinateur de toutes les manières possibles. Pierre, en tant que titan de la mémorisation - ne s'embarrasse pas de cela. Mais j'ai peur que le reste d'entre nous trouve cela assez stressant. Et l'on peut l'accepter juste pour bénéficier de quelques gros avantages. Hélas, je ne les vois pas. D'autant plus que Peter ne se concentre pas sur le trading automatique, mais sur le trading manuel.
Le secret de la mémorisation est que votre pensée doit être structurée. Vous devez regarder le code à travers la lentille de la POO, mais sans utiliser la POO elle-même. C'est ce que je fais. Vous avez la POO dans le programme, je l'ai dans ma tête.
C'est pourquoi je comprends les avantages de la POO et les avantages de son absence. Et vous ne bénéficiez que des avantages de la POO.
Le secret de la mémorisation est que votre pensée doit être structurée. Vous devez regarder le code à travers la lentille de la POO, mais sans utiliser la POO elle-même. C'est ce que je fais. Vous avez la POO dans le programme, je l'ai dans ma tête.
Par conséquent, je bénéficie des avantages de la POO et des avantages de son absence. Et vous ne bénéficiez que des avantages de la POO.
Ça me rappelle :
Ainsi, j'obtiens les avantages de la POO et les avantages de ne pas l'avoir. Et vous ne bénéficiez que des avantages de la POO.
Il est difficile de dire ce que vous voyez, mais je dirai que si vous prenez une classe toute faite, que vous amenez ses méthodes et ses champs à la portée globale (deploy), vous obtenez votre approche, puis vous appelez les champs le noyau et le moteur et obtenez... on obtient un code ingérable que l'on peut écrire à partir de rien, mais que l'on ne peut pas modifier.
ZS :
Pourquoi la POO est-elle intéressante ? - car le programmeur n'a pas besoin d'inventer sans cesse de nouveaux noms de variables ! - vous créez une classe de base, vous écrivez tout ce que vous voyez en ce moment et c'est tout..... Il n'est pas nécessaire d'hériter, il suffit de créer une instance de la classe (ou même un tableau de classes !) et de récupérer toutes les variables, qui sont divisées pour chaque objet (classe) en une seule fois ... La POO au moins est pratique, et la vitesse d'exécution... Vous travaillez toujours soit directement avec les registres du CPU, soit en utilisant des langages de plus haut niveau. En général, vous disposez d'une puissance de calcul suffisante pour écrire tout ce qui vous convient, si vous n'avez pas assez de puissance, vous commencez à profiler et à réécrire les segments de code problématiques - peu de gens le font.
Il est difficile de dire ce que l'on voit, mais je dirai que si l'on prend une classe toute faite, que l'on amène ses méthodes et ses champs à la portée globale (deploy), on obtient votre approche, puis on appelle les champs le noyau et le moteur et... on obtient un code ingérable que l'on peut écrire à partir de rien, mais que l'on ne peut pas modifier.
ZS :
Pourquoi la POO est-elle intéressante ? - parce que le programmeur n'a pas besoin d'inventer sans cesse de nouveaux noms de variables ! - vous créez une classe de base, vous écrivez tout ce que vous voyez en ce moment et c'est tout..... Il n'est pas nécessaire d'hériter, il suffit de créer une instance de la classe (ou même un tableau de classes !) et de récupérer toutes les variables, qui sont divisées pour chaque objet (classe) en une seule fois ... La POO au moins est pratique, et la vitesse d'exécution... Vous travaillez toujours directement avec les registres du processeur ou utilisez des langages de plus haut niveau, généralement vous avez assez de puissance de calcul pour écrire tout ce qui vous convient, si vous n'avez pas assez de puissance, vous commencez à profiler et à réécrire les sections de code qui posent problème - peu de gens le font.
Ce qui me répugne dans la POO, c'est un format rigide d'écriture du code. Comme vous l'avez vu, j'ai tendance à compiler de grands tableaux de données et je trouve cela très pratique. Dans la POO, je dois adhérer à un tas de règles, que je trouve personnellement très contraignantes.
En bref, je programme avec une OOP différente. Le mien. Il y a peu de règles et beaucoup de liberté. La fonctionnalité elle-même est placée dans de grands blocs, et les données sont organisées en noyaux. Je ne réfléchis même pas spécialement à leur structure. Tout se développe par lui-même. Au niveau intuitif.