Programmation OOP vs programmation procédurale - page 8

 
Dmitry Fedoseev:

Peut-être que ce n'est pas une approche rationnelle de charger tous les ordres ouverts avec tous leurs paramètres dans un tableau.


Peut-être, si j'ai besoin de deux paramètres profit et stop loss dans mon code, il est trop coûteux d'exécuter la boucle deux fois.

C'est un code universel et nous pouvons supprimer les choses inutiles pour accélérer le processus final...

 
Vladimir Pastushak:

Simplifier

C'est pour ça que je ne supporte pas les OOP. Il est impossible de comprendre quoi que ce soit. Il n'y a pas de commentaire. Que faut-il faire à la fin ?
 
Реter Konow:
C'est pour ça que je ne supporte pas les OOP. Il est impossible de comprendre quoi que ce soit. Il n'y a pas de commentaire. Que faut-il faire à la fin ?

Pourquoi ne pas commencer à l'apprendre ?

 
Реter Konow:
C'est pour ça que je déteste les OOP. Il est impossible de comprendre quoi que ce soit. Aucun commentaire. Que faut-il faire à la fin ?

C'est ça le problème : vous ne comprenez pas, mais vous avez une structure de tableau avec tous les ordres et facile à appeler n'importe où. Et vous n'exécutez la boucle lourde qu'une seule fois...

 
Dmitry Fedoseev:

Pourquoi ne pas commencer à l'apprendre ?

Remplit un tableau avec des valeurs de fonction dans une boucle. La question est de savoir pourquoi vous avez besoin d'un shell de classe. Vous pouvez vous en sortir avec une fonction.
 
Реter Konow:
Remplit le tableau avec les valeurs des fonctions dans la boucle. La question est de savoir pourquoi vous avez besoin d'un shell de classe. Vous pouvez le faire avec une fonction.

Moins il y a d'appels de fonctions, plus le code est rapide.

 
Реter Konow:
Remplir le tableau avec les valeurs des fonctions dans la boucle. La question est de savoir pourquoi vous avez besoin d'un shell de classe. Vous pouvez également le faire avec une fonction.

La structure est très pratique - pas besoin d'empiler des tableaux et de les redimensionner individuellement. Cet exemple ne montre pas les avantages de la POO, mais simplement que chacun le fait de la manière dont il est personnellement à l'aise.

 
Vladimir Pastushak:

C'est ça le problème : vous ne comprenez pas, mais vous avez une structure de tableau avec toutes les commandes et facile à appeler n'importe où. En même temps, vous n'exécutez la boucle lourde qu'une seule fois...

Je comprends pourquoi je ne le comprends pas, ce n'est pas mon code, et ce n'est qu'une partie de celui-ci. Mais vous ne semblez pas le comprendre non plus - ou ai-je tort ?
 
Dmitry Fedoseev:

Messieurs les argumentateurs, disons-le ainsi, si vous ne comprenez pas la POO, ne savez pas, alors discutons non pas de la programmation procédurale contre la POO, mais de la programmation procédurale avec des pointeurs vers des fonctions contre la programmation procédurale sans pointeurs vers des fonctions.

Non, votre exemple est très bon.

Il ne s'agit pas de programmation procédurale.

Il existe un critère de qualité des programmes bien plus important : la clarté du code.

La solution que vous avez donnée est affreuse : il n'est pas du tout clair QUELLE fonction est appelée de manière significative. J'écrirais un interrupteur normal et un commentaire pour chaque appel. C'est le bon code.

De votre exemple, je conclus que la POO est une chose nuisible.

 
Vladimir Pastushak:

Moins il y a d'appels de fonctions, plus le code est rapide.

C'est pourquoi j'aime faire de grands blocs de code génériques.
Raison: