Un point de vue intéressant sur l'OLP - page 5
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
Si la question porte sur mon exemple - au moins vous cachez l'implémentation (vous la cachez même à vous-même) - c'est-à-dire que vous n'écrivez que la logique des calculs, c'est pratique, c'est lisible, cela vous permet d'éviter les erreurs logiques...
SZZY : En ce qui concerne le trading, j'ai écrit et je fais encore des expériences avec des grilles d'ordres, où j'écris la logique de placement des ordres comme A + B - C, où A, B et C sont des ordres avec des paramètres prédéfinis, très utiles pour les algorithmes génétiques.
Les enveloppes sont une solution bonne et logique. Quand cela convient. Et je pense que les wrappers sont une innovation dans le langage procédural. Exactement dans le sens de la nouveauté et de l'utilité.
En ce qui concerne le commerce, j'ai fait et je fais encore des expériences avec des grilles d'ordres où j'écris la logique de placement des ordres comme A + B - C , où A, B et C sont des ordres avec des paramètres prédéfinis - c'est très utile pour les algorithmes génétiques- c'est un sujet intéressant.
A, B et C avec des paramètres prédéfinis- comme un phénotype pour les algorithmes génétiques ?
L'encapsulation donne la liberté des noms. Et si ce problème est résolu par la logique des noms. Ceci est bien sûr coûteux. alors python peut être écrit en fonctions. mais ce ne sera pas une solution commercialisable. MAIS C'EST POSSIBLE.
En python, toute fonction est un objet, tout comme une variable).
À propos, un exemple de POO continue est Python. Là, plutôt, personne ne sait que quelque chose d'autre que la POO existe.
il y a des fermetures et vous pouvez écrire sans POO du tout, du moins dans l'ancien système, comme vous voulez.
en python, toute fonction, comme une variable, est un objet)
Tout ce que vous pouvez faire, c'est utiliser des références pour tout résoudre, tant que les noms ne se chevauchent pas. Une fonction est bien sûr un objet, mais son résultat est unifié en interne, et ce n'est qu'en global et public que vous pouvez regarder à l'intérieur. j'aime la logique de python))))
il existe des fermetures et il est possible d'écrire sans oop du tout, dans l'ancienne version du moins, comme on voudra.
vous pouvez le faire, mais le bloc de construction minimum est toujours un objet
Je ne l'ai pas vu depuis un moment...
Est-il vraiment passé sous un autre pseudonyme ?
Non, ce n'est pas Peter, c'est un style d'écriture différent.
l'OOP d'entreprise le plus évident est Java. Dans notre domaine, Du* *opy est représenté (saupoudré pour ne pas être rattrapé). Si vous voulez la beauté des objets - essayez sobrement de comprendre et de vous souvenir de leur API, heureusement le thème est connu :-)
Mais c'est des conneries...
Pour améliorer vos compétences en programmation, vous voudrez peut-être apprendre quelque chose qui vous fera perdre la tête. Par exemple, il y a Rebol/Red ( https://www.red-lang.org/ )- un truc génial, c'est pas très clair mais c'est cool.
ou un classique, Smalltalk(https://pharo.org/). Quelqu'un l'utilise même en production.
Et tout ce "écrivons A+B dans des styles différents" est un jeu d'enfant, honnêtement.
Et alors toutes les questions sur qui est le plus cool, OOP ou FP, disparaîtront d'elles-mêmes.
Vous pouvez le faire, mais l'élément de base minimum reste l'installation.
l'objet était une percée.
Lorsque la POO est plus pratique, j'utilise la POO, lorsque j'ai besoin d'économiser de la mémoire et du temps, et de coder pour moi-même, je reste dans le procédural. Je suis juste tombé sur un article, je voulais écouter les opinions, où/quoi est mieux). Résultat - J'ai entendu beaucoup de choses différentes dans mon discours, pas sur la programmation) Tout comme d'habitude.
Donc personne ne vous dira rien de nouveau. Utilisez ce avec quoi vous êtes à l'aise, c'est tout.
Pour minimiser les erreurs, il existe tout un domaine appelé programmation probatoire (vérification formelle en particulier).
Comme mesure partielle pour améliorer la qualité du code, vous pouvez suggérer de suivre un style de codage commun (par exemple, le codestyle google), d'utiliser des assertions, des contraintes (const, override, access specifiers) qui n'affectent pas en fait l'exécution mais provoquent des erreurs de compilation si elles sont utilisées incorrectement, de vous familiariser avec les approches de la conception en général.
Le fait est qu'en dehors des domaines critiques de la programmation, il est généralement plus important de sortir rapidement la version de production que d'obtenir la qualité du code, ce qui est mal mais vrai