Parler de l'OLP dans le salon - page 11
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
La quantité de gestes dans la POO ne peut pas être moindre en principe, car toutes ces interfaces sont des frais généraux supplémentaires, qui dépassent souvent le coût d'écriture de la logique elle-même. Et ce, malgré le fait que toute fonction dispose déjà d'une interface, c'est-à-dire qu'il est proposé de construire un autre jardin, qui est essentiellement dépourvu de sens.
En même temps, toute modification du code, tant au niveau de l'interface que de la fonction, devient beaucoup plus compliquée, puisque l'un est accroché à l'autre, ce qui signifie que nous avons au moins une augmentation quadratique du nombre possible de bugs et de la pénibilité du travail... C'est assez évident, n'est-ce pas ?
La quantité de gestes dans la POO ne peut pas être moindre en principe, car toutes ces interfaces sont des frais généraux supplémentaires, qui dépassent souvent le coût d'écriture de la logique elle-même. Et ce, malgré le fait que toute fonction dispose déjà d'une interface, c'est-à-dire que nous devons faire encore une autre couverture qui est essentiellement inutile.
Dans ce cas, tout changement de code à la fois dans l'interface et dans la fonction devient beaucoup plus compliqué, car l'un est lié à l'autre, c'est-à-dire que nous avons une augmentation au moins quadratique des bogues possibles et de la pénibilité du travail... C'est assez évident, n'est-ce pas ?
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Parler de la programmation orientée objet dans l'arrière-cour
fxsaber, 2018.01.14 11:35
La programmation elle-même est un cas particulier de production. L'approche OOP est une approche de principe pour produire n'importe quoi. Parler de programmation est donc très étroit. La POO a été appliquée avec succès AVANT son apparition dans la programmation.
L'histoire de l'industrie est arrivée à la PRODUCTION orientée objet comme l'étape suivante de la convoyage. Parler de programmation OO est donc une vision étroite. Comme parler des bottes de couture OO. Nous parlons d'approches algorithmiques de l'organisation de toute production, y compris, comme un cas très particulier, la création de logiciels.
La production OOP s'est avérée compétitivement supérieure aux lignes d'assemblage conventionnelles. Il existe une planification à court terme de la production, lorsqu'il est nécessaire de la faire fonctionner maintenant. Et il y a le long terme - lorsque vous posez beaucoup d'"extra" pour le moment, mais que cette base est propice à une simple augmentation de la production. Encore une fois, il ne s'agit pas de programmation, mais d'approches générales de la création de production.
Les approches de la POO sont visibles même dans les institutions modernes du pouvoir.
Le terminal est une classe par rapport à votre code. À quelle fréquence devez-vous modifier quelque chose dans le code du terminal ?
Cet exemple est incorrect. Nous parlons d'interfaces au sein de votre programme...
L'histoire de l'industrie est arrivée à la PRODUCTION orientée objet comme l'étape suivante de la convoyage.
La programmation OO a également ses pipelines de traitement et OOP introduit une autre couche d'abstraction qui ne fait qu'augmenter les frais généraux de chaque convoyeur individuel et de la production entière.
La programmation OO a également ses propres convoyeurs de traitement, et la POO introduit encore une autre couche d'abstraction qui ne fait qu'augmenter les frais généraux de chaque convoyeur individuel et de l'ensemble de la production.
Vous êtes stupide, malheureusement. On vous parle de l'histoire de l'industrie et de la POO comme l'une des étapes de cette histoire, qui a joué un rôle énorme dans toutes les choses matérielles (et pas seulement) qui vous entourent. Et vous continuez à parler d'un cas particulier de programmation.
Ignorance de l'histoire du développement humain. Vous ne laisserez pas de trace dans la mémoire de vos descendants directs.
On vous parle de l'histoire de l'industrie et de la POO comme d'une étape de cette histoire, qui a joué un rôle énorme dans toutes les choses matérielles (et pas seulement) qui vous entourent.
Votre tentative naïve de faire entrer l'OLP dans l'histoire de l'industrie est amusante, mais malheureusement illettrée.
Cet exemple est incorrect. Nous parlons d'interfaces dans votre programme...
Pourquoi est-ce "incorrect" ?
En quoi un programme est-il différent de TOUS les logiciels fonctionnant sur un ordinateur ?
Après tout, il s'agit de la même série d'instructions et de jeux de données que dans tout programme utilisateur. Pourquoi est-il incorrect - ici ou là, une partie du logiciel n'a pas accès à une autre partie du logiciel autrement que par des protocoles d'échange établis ?
Ce n'est pas grave, si vous programmez sérieusement - tôt ou tard, vous arriverez à la nécessité de différencier les droits d'accès.
Moi aussi, à l'époque où je passais du mode réel au mode sécurisé, je détestais ne pas pouvoir accéder à une adresse mémoire physique. J'ai même fabriqué des twists avec un contrôleur DMA qui copiait les données d'une zone système protégée vers la mienne (bien qu'il était assez difficile de comprendre ce qui était copié là, donc je ne l'ai pas fait). Dans ma jeunesse, j'étais indigné - comment pouvais-je ne pas avoir d'accès direct - c'était presque une atteinte à mes droits... Et qu'en est-il du programme visant à rendre quelque chose indisponible pour moi ?
Eh bien, en accumulant de l'expérience, j'ai souvent constaté que la différenciation des droits d'accès est une aubaine pour le programmeur lui-même, car elle m'a souvent évité de faire des erreurs dans les modules écrits. Vous prenez une classe, vous voulez l'utiliser, et elle n'a pas accès à certaines données... Vous êtes indigné, comment est-ce possible, vous commencez à chercher... et oups... Il y a des choses à prendre en compte et les données ne sont pas accessibles directement, il y a des "moyens indirects", l'architecture du système est telle que je peux obtenir des données invalides en y accédant directement. Mais je peux aussi obtenir des données valables - tout dépend du moment. Et une telle erreur est très difficile à détecter.
Ici, le problème le plus simple est d'accéder aux données dans un cache. Si vous avez besoin de données en cache et que vous y accédez directement, êtes-vous sûr d'obtenir les bonnes données ? Dans l'approche procédurale sans différenciation - vous devez comprendre quand vous pouvez l'utiliser, quand vous ne pouvez pas, quand les données sont valides, quand elles ne le sont pas... Dans l'approche POO - tout est très simple, vous n'avez pas accès aux données du cache, vous pouvez seulement appeler la fonction, qui renvoie les données requises, et si elles ne sont pas valides, elle va chercher les données valides. Imaginez maintenant que vous utilisez ce cache un an après l'avoir écrit. Lorsque vous avez complètement oublié les principes de rafraîchissement du cache et de définition de la validité. Dans l'approche OOP, vous ne vous en souciez pas. La fonction de classe vous fournira tout. Mais dans l'approche fonctionnelle, vous devez vous rappeler en détail quand et comment le cache est mis à jour, quand les données qu'il contient sont valides et quand elles ne le sont pas.
Cet exemple est incorrect. Nous parlons des interfaces au sein de votre programme...
Le terminal est une classe par rapport à votre code. Combien de fois avez-vous besoin de modifier quelque chose dans le code du terminal qui vous est caché et qui ne dispose que de méthodes publiques - des fonctions pour mettre en œuvre vos programmes.
+++ )))
Le terminal est une classe par rapport à votre code. Combien de fois avez-vous besoin de modifier quelque chose dans le code du terminalqui vous est caché, et seules les méthodes publiques - les fonctions pour la mise en œuvre de vos programmes sont fournies.
Un tel besoin se présente régulièrement. Il est souhaitable que les développeurs le fassent.
Un exemple simple. Pour une raison quelconque, les développeurs n'ont pas jugé nécessaire de fournir une grille de coordonnées horizontales pour les graphiques indicateurs. Et bien sûr, ils n'ont pas fourni de méthode appropriée pour cela).