Programmation OOP vs programmation procédurale - page 36
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
1. Pas dans une certaine mesure. La rentabilité ne dépend pas de l'AOP.
2. A mon avis, d'un ordre de grandeur (décuplé). Mais le principal avantage de la POO réside dans le support du code. Maintenant, je peux très rapidement retrouver le code que j'ai écrit il y a un an ou plus. Je me souviens bien de la façon dont j'ai compris mes premiers programmes ANSI C dans un style purement procédural. C'était beaucoup plus difficile.
1. C'est la principale réponse à la nécessité de la POO.
2. c'est une question d'expérience en équipe. J'ai écrit tout ce dont j'avais besoin. Il y a quelques années, j'ai décidé d'écrire un peu plus - tout se lit, sans problème.
De vos réponses, j'ai compris une chose : la POO est un certain standard qui introduit la discipline de la programmation, introduit l'uniformité et sur cette base, moins d'erreurs au départ et, surtout et surtout, elle réduit en principe les problèmes de modification. Mais le même résultat a été obtenu en respectant scrupuleusement les GOST, les étapes du développement, la documentabilité.
Je ne comprends pas pourquoi je n'ai JAMAIS rencontré une telle chose dans mon travail. Pourquoi y aurait-il un problème de différenciation d'accès variable pour UN développeur dans un programme pas si important que ça ? Il y aurait 100 développeurs, chacun écrivant 100 fonctions. Théoriquement, on pourrait l'inventer. Mais en pratique, la programmation a évolué vers la POO depuis presque 40 ans, des montagnes de code ont été écrites et je n'ai jamais rien entendu de tel.
Au début, les programmes étaient écrits en code.
La POO est simplement une technologie qui permet d'écrire des programmes plus complexes plus rapidement et de les maintenir plus efficacement.
Mais cela ne signifie pas que la POO est une panacée. Je dis que si vous avez de la mémoire comme Peter, vous n'avez pas besoin de la POO du tout - déclarez tout globalement et faites-en ce que vous voulez, puisque vous vous souvenez de tout et que vous pouvez facilement éviter les collisions ou les mélanges de variables. Mais, j'ai une mémoire bien pire. Et la délimitation - je l'utilise beaucoup. Ces dernières années, j'ai beaucoup aimé le modificateur const - je l'utilisais rarement auparavant. Maintenant, je l'utilise très souvent. Juste pour avoir accès uniquement à ce dont j'ai besoin et pas plus. Pour que cet accès soit en lecture seule aux endroits où il n'est pas prévu de le modifier.
George Merts:
Oui, en effet, il y a des situations où il s'avère soudainement qu'il est presque impossible d'obtenir les données dont vous avez besoin. Ils sont cachés derrière plusieurs interfaces virtuelles. Cependant, cette situation montre clairement que le système n'a pas été conçu correctement à l'origine, il ne prévoyait pas le transfert de ces données. Cette situation est en effet très désagréable. Nous devons soit construire à la hâte des "béquilles" sous la forme d'interfaces supplémentaires, soit restructurer l'ensemble du système. Enfin... elle incite le programmeur à réfléchir plus attentivement à l'architecture du système.
Si le programmeur est un prophète et un clairvoyant, qu'il voit à l'avance et dans tous les détails de la structure de données nécessaire pour toutes les variantes possibles de l'idée principale, alors il est probablement logique d'agir à votre manière. Ou bien le faire au stade final, lorsque tout fonctionne déjà et que le code est débogué sans utiliser ces compléments, mais encore une fois, à condition que rien ne doive jamais être modifié et réorganisé...
1. C'est la principale réponse à la nécessité de la POO.
2. c'est une question d'expérience en équipe. J'ai écrit tout ce dont j'avais besoin. Il y a quelques années, j'ai décidé d'écrire un peu plus - tout se lit, sans problème.
De vos réponses, j'ai compris une chose : la POO est une certaine norme qui introduit la discipline de la programmation, introduit l'uniformité et sur cette base, moins d'erreurs au départ et, surtout et surtout, les problèmes lors de la modification sont essentiellement réduits. Mais le même résultat a été obtenu en respectant scrupuleusement les GOST, les étapes du développement, la documentabilité.
1. Non. La POO n'est pas un outil pour assurer la rentabilité. Et vous ne pouvez pas parler de la nécessité de la POO tout en regardant la rentabilité. La POO est un outil permettant de simplifier le développement et la maintenance du code.
2. c'est cool quand les CT d'il y a dix ans fonctionnent encore. Je ne peux pas vivre comme ça, ils cessent régulièrement de fonctionner pour moi, je dois constamment les modifier. Et la POO m'est d'une grande aide à cet égard.
Et à propos de OOP - certains standards, oui, tout est vrai. Et il est vrai que l'on peut obtenir le même résultat si l'on reste échelonné et documenté. Mais il me semble que cela demande plus d'efforts que dans le cas de la POO.
Au début, les programmes étaient écrits en code.
La POO est simplement une technologie qui vous permet d'écrire des programmes plus complexes plus rapidement, puis de les maintenir plus efficacement.
Mais cela ne signifie pas que la POE est une panacée. Je dis que si vous avez de la mémoire comme Peter, vous n'avez pas besoin de la POO du tout - déclarez tout globalement et faites-en ce que vous voulez, puisque vous vous souvenez de tout et que vous pouvez facilement éviter les collisions ou les mélanges de variables. Mais, j'ai une mémoire bien pire. Et la délimitation - je l'utilise beaucoup. Ces dernières années, j'ai beaucoup aimé le modificateur const - je l'utilisais rarement auparavant. Maintenant, je l'utilise très souvent. Juste pour que je n'aie pas accès uniquement à ce dont j'ai besoin et pas plus. Pour que cet accès soit en lecture seule aux endroits où il n'est pas prévu de le modifier.
Au début, les programmes étaient écrits en code.
Ne déformons pas les choses, d'accord ?
La POO est simplement une technologie qui vous permet d'écrire des programmes plus complexes plus rapidement et de les maintenir plus efficacement.
C'est discutable, et très discutable.
Des programmes plus rapides sont écrits et maintenus efficacement s'ils ont une bonne documentation de conception. On trouve des échos de ce problème sur le marché, où l'on accorde une grande attention aux RPT. Si le RPT est mauvais, aucune OOP ne sera utile.
Les programmes dotés d'une bonne documentation de projet sont rédigés et maintenus plus rapidement et plus efficacement. On trouve des échos de ce problème sur le marché, où l'on accorde une grande attention aux RPT. Si le RPT est mauvais, aucune OOP ne sera utile.
Si le programmeur est un prophète et un clairvoyant, voyant à l'avance et dans tous les détails la structure de données nécessaire pour toutes les variantes possibles de la mise en œuvre de l'idée principale, alors il est probablement logique d'agir à votre manière. Ou bien le faire au stade final, lorsque tout fonctionne déjà et que le code est débogué sans utiliser ces compléments, mais encore une fois, à condition que rien ne doive jamais être modifié et réorganisé...
La POO est simplement une technologie qui vous permet d'écrire des programmes plus complexes plus rapidement, puis de les maintenir plus efficacement.
Comme expliqué ci-dessus, la POO n'est pas destinée à l'origine à l'écriture et au débogage rapides du code en raison des nombreux wrappers, superstructures intermédiaires et adaptateurs... Cela n'a de sens qu'au stade final, lorsque tout fonctionne et est débogué et que la structure de données a acquis sa forme définitive... C'est-à-dire qu'il s'agit d'une procédure purement cosmétique d'emballage d'un code prêt pour un stockage ultérieur...
Mais une autre chose est plus importante pour moi - Igor l'a correctement dit plus haut - chaque classe n'est responsable que de ses propres variables, il est impossible d'"entrer" dans les variables de quelqu'un d'autre à partir d'elle. Par conséquent, la plupart des problèmes sont coupés à l'étape de la compilation.
Une classe n'a que des variables internes et aucune variable d'entrée ou de sortie... Où avez-vous vu l'utilisation en programmation d'un tel objet qui n'a aucun contact avec le monde extérieur et qui bout dans son propre jus ?
.... Les programmes modernes n'ont pratiquement pas besoin de documentation - tout se trouve dans la paume de votre main dans les interfaces des classes.
Expliquez cela aux métaquotes : pourquoi ont-ils écrit d'énormes manuels pour le terminal, pour le langage et en général, où est née cette montagne de documentation pour les produits logiciels sur par exemple Cp.... En fait, existe-t-il des produits logiciels sans documentation ? C'est étrange que vous ne le remarquiez pas.