Programmation OOP vs programmation procédurale - page 26
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
Il n'y a pas grand-chose à penser.
La POO est un mécanisme qui nous permet de passer un grand nombre de contrôles et d'approbations au compilateur. Cependant, nous devons fournir un effort supplémentaire pour l'utiliser.
Mais si nous n'avons pas besoin de tous ces contrôles et ajustements, il n'y a aucun sens à utiliser la POO.
Par exemple, je me méfierais de travailler avec un tableau multidimensionnel de noyaux graphiques - car il comporte trop d'entités inutiles qui ne sont pas nécessaires pour le moment. Ils sont distrayants et provoquent des erreurs difficiles à calculer. Je le remplacerais par un ensemble d'objets, auxquels j'accéderais par des interfaces simples et compactes. En obtenant une interface - je ne dois rien retenir - l'interface elle-même me limite et m'empêche, par exemple, d'accéder au mauvais champ ou objet. Dans le cas d'un tableau de noyau graphique, une telle manipulation est très possible.
C'est-à-dire que dans le cas où un bloc reçoit une interface, le compilateur lui-même "coupe" toutes les entités inutiles et empêche l'utilisateur de faire une erreur. Mais dans le cas d'un tableau de noyaux graphiques, l'utilisateur dispose d'un grand nombre d'informations inutiles où il peut facilement faire une erreur.
D'après mon expérience, je sais que je suis bien mieux loti lorsque le compilateur lui-même garde la trace des choses que je ne dois pas aller où je ne dois pas aller dans le bloc actuel. Et avec un tableau graphique du noyau - je dois m'en souvenir. Le moins de mon système est une extension du plus. Si j'ai soudainement besoin de quelque chose dans un bloc qui va au-delà de la tâche en cours, avec un tableau de noyau graphique, c'est facile - il suffit de prendre les données nécessaires et de travailler avec elles. Mais avec les interfaces OOP, vous devrez soit demander les données nécessaires dans une interface supplémentaire, soit (ce qui est beaucoup plus désagréable) modifier l'interface existante.
Il n'y a pas grand-chose à penser.
La POO est un mécanisme qui nous permet de passer un grand nombre de contrôles et d'approbations au compilateur. Cependant, nous devons fournir un effort supplémentaire pour l'utiliser.
Mais si nous n'avons pas besoin de tous ces contrôles et ajustements - il n'y a aucun sens à la POO.
Mais pourquoi le simplifier à ce point ? Et qu'en est-il de la clarté et de la lisibilité ? Et la simplicité de la détection et de la correction des erreurs ? Et la portabilité ? Et la facilité de mise à niveau ? etc., etc. ....
Alors, le thème devrait sonner différemment. Quelque chose comme : "Une nouvelle boîte à outils en programmation" ou "Un nouveau paradigme de programmation"...
Si c'est vrai que tu as créé quelque chose de plus cool que OOP, alors tu dédicaceras le tien quand tu seras célèbre ?
Pas de problème ! Aucune dépense n'a été épargnée pour obtenir un autographe pour vos amis. ))))
Vous plaisantez, mais dans mon imagination, j'ai un tel point de vue sur cette approche que c'est une vraie déception. Il semble qu'avec le temps, je serai en mesure de lancer le mécanisme d'auto-amélioration du système. Si je crée un noyau logique et qu'il génère aléatoirement différents mécanismes. Il suffit ensuite de faire une sélection et de choisir les bons. Puis les rectifier un peu... grâce au noyau, des choses incroyables peuvent être faites.
Pourquoi simplifier autant les choses. Et la clarté et la lisibilité ? Et la facilité de détection et de correction des erreurs ? Qu'en est-il de la portabilité ? Et la facilité de mise à niveau ? etc., etc. ....
belle bannière publicitaire :-) "achetez nos éléphants".
toutes ces thèses sont également applicables à la POO et à la non-POO, à la PF et à tout autre domaine.
Il n'y a pas grand-chose à penser.
La POO est un mécanisme qui nous permet de passer un grand nombre de contrôles et d'approbations au compilateur. Cependant, nous devons fournir un effort supplémentaire pour l'utiliser.
Mais si nous n'avons pas besoin de tous ces contrôles et ajustements, il n'y a aucun sens à utiliser la POO.
Par exemple, je me méfierais de travailler avec un tableau multidimensionnel de noyaux graphiques - car il comporte trop d'entités inutiles qui ne sont pas nécessaires pour le moment. Ils sont distrayants et provoquent des erreurs difficiles à calculer. Je le remplacerais par un ensemble d'objets, auxquels j'accéderais par des interfaces simples et compactes. En obtenant une interface - je ne dois rien retenir - l'interface elle-même me limite et m'empêche, par exemple, d'accéder au mauvais champ ou objet. Dans le cas d'un tableau de noyau graphique, une telle manipulation est très possible.
C'est-à-dire que dans le cas où un bloc reçoit une interface, le compilateur lui-même "coupe" toutes les entités inutiles et empêche l'utilisateur de faire une erreur. Mais dans le cas d'un tableau de noyau graphique, l'utilisateur dispose d'un grand nombre d'informations inutiles où il peut facilement faire une erreur.
D'après mon expérience, je suis bien mieux loti lorsque le compilateur lui-même garde la trace des choses que je ne devrais pas faire dans le bloc actuel. Et avec un tableau graphique du noyau - je dois m'en souvenir. Le moins de mon système est une extension du plus. Si j'ai soudainement besoin de quelque chose dans un bloc qui va au-delà de la tâche en cours, avec un tableau de noyau graphique, c'est facile - il suffit de prendre les données nécessaires et de travailler avec elles. Mais avec les interfaces OOP, vous devrez soit demander les données nécessaires dans une interface supplémentaire, soit (ce qui est beaucoup plus désagréable) modifier l'interface existante.
Vous avez tort de penser que le noyau est redondant. Et il est très facile de se souvenir de ses entités car elles sont habillées de mots humains par le biais de définitions. Tout y est rassemblé, mais ce contenu a un ordre clair et immuable. Les propriétés des objets, fenêtres et éléments sont directement accessibles à tout moment du programme. Et quelles merveilles on peut faire avec le noyau dans les boucles...
Vous avez tout à fait tort de penser qu'il y a quelque chose en plus dans le noyau. Et il est très facile de se souvenir de ses entités, car elles sont habillées de mots humains par le biais de définitions. Tout y est rassemblé, mais ce contenu a un ordre clair et immuable. Les propriétés des objets, fenêtres et éléments sont directement accessibles à tout moment du programme. Et quelles merveilles vous pouvez faire grâce au noyau en boucle...
Je n'ai pas dit que "le noyau est redondant", j'ai dit "inutile pour le moment". Si je travaille avec une ligne graphique, je ne devrais pas pouvoir accéder aux propriétés de la fenêtre.
Le simple fait que toutes ces propriétés soient directement accessibles n'importe où dans le programme constitue le principal inconvénient de votre approche. À n'importe quel endroit du programme, seuls les éléments qui sont nécessaires à ce moment précis doivent être accessibles. Tout le reste devrait être indisponible. Cela - vous permet d'éviter automatiquement de nombreuses erreurs.
Toutes les "merveilles qui peuvent être réalisées grâce à l'accessibilité de l'ensemble du noyau" sont, à mon avis, une source potentielle d'erreurs difficiles à trouver et de problèmes de compréhension du code. Il faut essayer d'éviter toutes ces astuces.
Cette approche me rappelle des tâches très stupides où les pointeurs, les incréments et les références sont écrits en une seule ligne dans un fouillis qui est peut-être correct du point de vue du langage mais pas du tout lisible. J'ai cité ma propre fonction ci-dessus, qui a également l'air complètement folle, mais je me suis dit que la compacité était plus importante dans ce cas.
Eh bien, pourquoi le simplifier autant ? Et la clarté et la lisibilité ? Et la facilité de détecter et de corriger les erreurs ? Et la portabilité ? Et la facilité de mise à niveau ? etc., etc. ....
Fantastique !
1. Avant l'opération, nous construisions tout à partir de composants sur mesure avec des outils exceptionnellement complexes.
2. Avant la POO, les programmes étaient une compote exceptionnellement bien mélangée
3. Avant la POO, nous n'avions PAS entendu parler de la localisation des données et du code et cela rendait notre maintenance extrêmement pénible.
4. La protection des données entre les différentes parties d'un même programme était un cauchemar !
5. Avant la POO, personne n'étendait jamais les systèmes.
C'est un échec total.
Je m'assois et je pense que peut-être cette OOP est née de moi parce que j'ai appliqué tout cela à la fin des années 70 et bien d'autres choses liées à la culture de la programmation.
Je n'ai pas dit "il y a quelque chose d'inutile dans le noyau", j'ai dit "inutile pour le moment". Si je travaille avec une ligne graphique, je ne devrais pas pouvoir accéder aux propriétés de la fenêtre.
Le simple fait que toutes ces propriétés soient directement accessibles n'importe où dans le programme constitue le principal inconvénient de votre approche. À n'importe quel endroit du programme, seuls les éléments qui sont nécessaires à ce moment précis doivent être accessibles. Tout le reste devrait être indisponible. Cela - vous permet d'éviter automatiquement de nombreuses erreurs.
Toutes les "merveilles qui peuvent être réalisées grâce à l'accessibilité de l'ensemble du noyau" sont, à mon avis, une source potentielle d'erreurs difficiles à trouver et de problèmes de compréhension du code. Il faut essayer d'éviter toutes ces astuces.
Cette approche me rappelle les tâches les plus stupides où les pointeurs, les incréments et les références sont écrits en une seule ligne dans un désordre qui peut être correct du point de vue du langage mais qui est absolument illisible. J'ai cité ma propre fonction ci-dessus, qui a également l'air complètement folle, mais je me suis dit que la compacité était plus importante dans ce cas.
Vous raisonnez sur le noyau à partir de notions théoriques momentanées basées sur votre expérience, qui n'a rien à voir avec la technologie dont vous parlez. D'où certains problèmes d'accès, de mémorisation des entités...
Je raisonne à partir d'une expérience pratique de cette technologie, et je dis qu'il n'y a pas de tels problèmes d'accès ou de limitation. Honnêtement, je ne sais pas du tout de quels problèmes d'accès vous parlez. Il n'y a pas de tels problèmes et il n'y en a jamais eu.
Veuillez préciser à quels problèmes d'accès vous faites référence.
Qu'est-ce qui vous fait penser que l'accès doit être restreint si cela peut provoquer des erreurs ? C'est quelque chose de nouveau pour moi.
L'accès direct à un tableau global dans un code de procédure peut-il provoquer à lui seul des erreurs difficiles à détecter ?
Vous parlez du noyau à partir de notions théoriques immédiates basées sur votre expérience, ce qui n'a rien à voir avec la technologie dont vous parlez. D'où certains problèmes d'accès, de mémorisation des entités...
Je raisonne à partir d'une expérience pratique de cette technologie, et je dis qu'il n'y a pas de tels problèmes d'accès ou de limitation. Honnêtement, je ne sais pas du tout de quels problèmes d'accès vous parlez. Il n'y a pas et il n'y a jamais eu de telles difficultés.
Qu'entendez-vous par "aucun problème" lorsque vous dites "tout est accessible de partout" ?
C'est le principal problème ! Il ne devrait pas être accessible !
L'objectif est de transférer la tâche du contrôle d'accès au compilateur. Tout est ouvert, et le programmeur contrôle l'accès.
Il n'y a pas eu de complications parce que vous vous souvenez de tout. Vous y êtes habitué maintenant. Eh bien, vous finirez par constater que votre mémoire commence à vous faire défaut, et vous apprécierez alors la capacité du compilateur à contrôler les accès. Je ne me souviens pas. Et je soupçonne que la plupart des gens oublient aussi périodiquement comment fonctionne quelque chose écrit il y a plusieurs mois. C'est dans ces circonstances que le contrôle d'accès devient une aubaine.
Par exemple, si vous êtes à l'intérieur du bloc qui est responsable de passer des commandes - vous avez seulement la capacité de passer des commandes. Et vous n'avez pas la capacité de dessiner un graphique. Si vous vous trouvez dans un bloc chargé de dessiner un graphique, vous ne pouvez pas passer d'ordre à partir de ce bloc. Cela simplifie grandement le travail. Et lorsque, dans la fonction de tracé de graphique, vous voyez soudain une demande de passer un ordre, vous devrez vous rappeler longtemps pourquoi vous avez fait cela. Il serait bien qu'il y ait un commentaire détaillé expliquant pourquoi cette décision a été prise... Mais c'est mieux lorsque les commandes sont passées dans un seul bloc dédié.
Comment peut-il y avoir "aucun problème" si vous dites "tout est accessible de n'importe où" ?
C'est le principal problème ! Il ne doit pas être accessible !
Il s'agit simplement de transférer la tâche du contrôle d'accès au compilateur. Tout est ouvert, et le programmeur contrôle l'accès.
Il n'y a pas eu de complications parce que vous vous souvenez de tout. Vous y êtes habitué maintenant. Eh bien, vous finirez par constater que votre mémoire commence à vous faire défaut, et vous apprécierez alors la capacité du compilateur à contrôler les accès. Je ne me souviens pas. Et je soupçonne que la plupart des gens oublient aussi périodiquement comment fonctionne quelque chose écrit il y a plusieurs mois. C'est dans ces circonstances que la délimitation de l'accès devient une aubaine.
Par exemple, si vous êtes à l'intérieur du bloc qui est responsable de passer des commandes - vous avez seulement la capacité de passer des commandes. Et vous n'avez pas la capacité de dessiner un graphique. Si vous vous trouvez dans un bloc chargé de dessiner un graphique, vous ne pouvez pas passer d'ordre à partir de ce bloc. Cela simplifie grandement le travail. Et lorsque, dans la fonction de tracé de graphique, vous voyez soudain une demande de passer un ordre, vous devrez vous rappeler longtemps pourquoi vous avez fait cela. Il serait bien qu'il y ait un commentaire détaillé expliquant pourquoi cette décision a été prise... Mais c'est mieux lorsque les commandes sont passées dans un seul bloc dédié.