Parler de l'OLP dans le salon - page 10
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
Pas besoin d'imposer, mais il est évident que sous une forme procédurale, la logique du code est déjà visible sans gestes supplémentaires, et chaque geste d'un programmeur engagé coûte un droit à l'employeur. Par conséquent, si un employeur est intelligent, il ne se laissera pas duper par la POO, mais un programmeur intelligent peut déformer une histoire sur la POO progressive pour lui soutirer plus d'argent en profitant de son faible niveau d'alphabétisation. :)
Ha !
Il n'y a pas d'effort supplémentaire à faire pour se déplacer à pied, mais pour une raison quelconque, tout le monde veut prendre les transports. On en arrive au point de l'idiotie : ils montent dans une voiture, font deux kilomètres pour se rendre dans un centre de fitness, puis "ventent" cinq kilomètres sur un tapis de course.
En parlant de programmation, sous DOS, une fenêtre est créée simplement en l'écrivant dans un tampon vidéo. Mais pour créer une simple fenêtre dans Windows - vous devez enregistrer une classe de fenêtre, la créer et exécuter une boucle de traitement des messages - mais pour une raison quelconque, tout le monde fait ces "étapes supplémentaires".
L'OOP - n'est pas du tout choisi pour sa "progressivité", mais pour les avantages que cette méthodologie procure, et parce qu'elle est finalement moins chère pour l'employeur. Parce qu'après avoir écrit quelque chose en style procédural, vous ne pouvez pas le maintenir avec la même efficacité qu'en style POO.
Une bonne illustration - le code de Peter Konov - d'une part, un code orienté procédure tout à fait normal, mais d'autre part, pour travailler avec lui, vous devez toujours garder à l'esprit un grand nombre d'informations sur la structure du système, que personnellement je n'entreprendrai pas une telle tâche même pour beaucoup d'argent. En même temps, le SB écrit dans le style OOP est très facile à maintenir et à modifier. L'architecture des objets dans le modèle TC de la bibliothèque standard est beaucoup plus complexe que dans le code de Peter, mais elle est beaucoup plus facile à comprendre et à modifier.
Tout le discours sur "un style procédural sans travail supplémentaire" ne vaut que lorsqu'il s'agit d'écrire une structure vraiment complexe, et surtout d'y apporter des modifications. C'est pourquoi la POO est si largement utilisée - elle est plus facile pour les programmeurs et moins chère pour les clients. Cependant, pour faire quelque chose de très simple, il faut faire des "gestes inutiles". Simplement, personne n'a besoin de ce "simple", tous ont besoin de "complexe", ce qui est mieux d'être fait avec l'utilisation de la POO.
P.S. Et je ne comprends toujours pas, comment vous (parlons de "Vous") proposez de limiter l'accès aux fonctions, qui ne devraient être utilisées nulle part sans modificateurs d'accès OOP ?
George Merts:
Parce que si vous écrivez quelque chose en style procédural, vous ne pourrez pas le maintenir avec la même efficacité que quelque chose écrit en style OOP.
P.S. Et je ne comprends toujours pas, comment vous (parlons de "vous") proposez de limiter l'accès aux fonctions, qui ne devraient être utilisées nulle part sans modificateurs d'accès OOP ?Non, non. C'est juste l'inverse.
Il s'agit d'un code OOPeshe qui est difficile à maintenir et à modifier car il comporte de nombreux rebondissements et il est plus facile de réécrire le code par la suite. En fait, il est dit que le but de la POO est de cacher la logique, donc ils l'ont cachée, et si soudainement il est nécessaire de l'ouvrir, c'est un service avec un paiement supplémentaire.
Function wrapper permet de cacher les fonctions internes, mais si vous avez soudainement envie d'ajouter cette fonction interne pour ce que vous voulez, vous pouvez la cacher dans une DLL, ou le code source dans un fichier séparé, et le fichier dans le répertoire le plus éloigné, de sorte qu'il ne sera pas trouvé même si vous essayez, peut-être qu'il y a plus d'options pour les programmeurs particulièrement enragés. :)
Non, ça ne l'est pas. C'est juste l'inverse.
Le code OOP est tout aussi difficile à maintenir et à modifier, car la logique y est cachée par de nombreuses astuces différentes, ce qui facilite la réécriture du code. En fait, il est dit que le but de la POO est de cacher la logique, donc ils l'ont cachée, et si soudainement il est nécessaire de la découvrir, c'est un service avec des frais supplémentaires.
La fonction Wrapper vous permet de cacher les fonctions internes, mais si vous voulez soudainement ajouter cette fonction interne pour quoi que ce soit, vous pouvez la cacher dans une DLL, ou le code source dans un fichier séparé, et le fichier dans le répertoire le plus éloigné, de sorte qu'au mieux le désir il ne pourrait pas être trouvé, peut-être il y a des options pour les programmeurs particulièrement enragés. :)
Pourquoi serait-il "difficile à modifier" si la logique est cachée ? C'est pourquoi la logique est cachée, pour vous empêcher de modifier quoi que ce soit là où cela ne peut être fait.
C'est juste qu'en approche procédurale, vous voulez changer quelque chose, vous le changez, et ensuite vous ne comprenez pas pourquoi cela ne fonctionne pas (ou pire - parfois vous obtenez des erreurs incompréhensibles). Et dans l'approche OOP, vous voulez le changer - et vous n'avez pas accès aux internes de la classe. Et s'il n'y a pas d'accès, cela signifie que c'est fait pour une raison, qu'il y a quelque chose de délicat, des conditions d'utilisation implicites. Respectivement, si vous voulez changer quelque chose, vous pouvez prendre cette même classe, hériter de sa propre classe et y changer ce dont vous avez besoin, puisque vous avez déjà accès aux méthodes de protection dans le descendant.
Et même si vous en héritez, vous pouvez tomber sur une méthode ou un champ privé qui n'est pas disponible, même dans le descendant, et là encore, pour une raison précise, cela signifie que ce champ n'est pas destiné à être modifié, même dans le descendant.
En ce qui concerne le "cacher dans une DLL", le problème est que vous ne pouvez que cacher TOUT dans une DLL. Pas une partie de l'objet. Et c'est à cela que sert le modificateur d'accès, pour ne cacher qu'une partie de l'objet. C'est pour cela que tout est conçu - pour permettre au programmeur, à chaque endroit du programme, de n'avoir accès qu'à ce dont il a besoin, et rien "d'en haut" - cela permet de ne pas avoir peur qu'il puisse accidentellement changer non pas ce dont il a besoin, mais qu'il puisse changer la partie, qui est autorisée à être modifiée. Quel est l'intérêt de la DLL alors ? Ouvrez le code DLL - alors le code entier est ouvert, pas des parties. Fermer - à nouveau, tous les accès sont fermés.
Je ne sais pas comment limiter l'accès dans le style procédural sans utiliser les sections privées-protégées-publiques. Et cette restriction m'aide beaucoup.
Pourquoi serait-il "difficile à modifier" si la logique est cachée ? La logique est cachée pour que vous ne puissiez pas modifier quoi que ce soit là où vous ne le pouvez pas.
C'est juste qu'en approche procédurale, vous voulez changer quelque chose, vous le changez, et ensuite vous ne comprenez pas pourquoi cela ne fonctionne pas (ou pire - parfois vous obtenez des erreurs incompréhensibles). Et dans l'approche OOP, vous voulez le changer - et vous n'avez pas accès aux internes de la classe. Et s'il n'y a pas d'accès, cela signifie que c'est fait pour une raison, qu'il y a quelque chose de délicat, des conditions d'utilisation implicites. Respectivement, si vous voulez changer quelque chose, vous pouvez prendre cette même classe, hériter de sa propre classe et y changer ce dont vous avez besoin, puisque vous avez déjà accès aux méthodes de protection dans le descendant.
Et même si vous en héritez, vous pouvez tomber sur une méthode ou un champ privé qui n'est pas disponible même dans le descendant, et encore une fois, pour une raison, cela signifie que ce champ n'est pas destiné à être modifié même dans le descendant.
En ce qui concerne le "cacher dans une DLL", le problème est que vous ne pouvez que cacher TOUT dans une DLL. Pas une partie de l'objet. Et c'est à cela que sert le modificateur d'accès, pour ne cacher qu'une partie de l'objet. C'est pourquoi tout est conçu - pour permettre au programmeur, à chaque endroit du programme, de n'avoir accès qu'à ce dont il a besoin, et rien "d'en haut" - cela permet de ne pas avoir peur qu'il puisse accidentellement changer non pas ce dont il a besoin, mais qu'il puisse changer la partie, qui est autorisée à être modifiée. Quel est l'intérêt de la DLL alors ? Ouvrez le code DLL - alors le code entier est ouvert, pas des parties. Fermez-la - là encore, tout accès est fermé.
Je ne sais pas comment on peut limiter l'accès dans le style procédural sans utiliser des sections privées-protégées-publiques. Et cette restriction m'aide beaucoup.
George, vous battez à nouveau le tambour )))) Cela n'a aucun sens.
Georges, tu tournes encore autour du pot )))) Ça n'a aucun sens.
Peut-être, peut-être.
Mais tu es un Casanova à temps partiel... Et je suis un tuteur à temps partiel. Je vois que "le client n'est pas perdu". Alors je continue à expliquer. Comme "déformation professionnelle".
Peut-être, peut-être.
Mais tu es le Casanova à temps partiel... Et je suis un tuteur à temps partiel. Je vois que "le client n'est pas perdu". Donc, je continue à m'expliquer. Comme "déformation professionnelle".
J'en ai assez des Casanovas. Vous avez inventé un conte de fées et y avez cru vous-même) comme un enfant croit au Père Noël, pour l'amour de Dieu).
Il n'est pas nécessaire de l'imposer, mais il est évident que dans la forme procédurale la logique du code est déjà vue sans gestes supplémentaires, et chaque geste d'un programmeur engagé coûte de l'argent à l'employeur.
La quantité d'efforts corporels dans le code de procédure ci-dessus devra être augmentée si des modifications doivent être apportées.
Il est possible d'écrire du code sans fonctions (procédures). Mais le codage a fini par cesser d'être écrit en "coulant du béton" et a commencé à être construit à partir de "briques". C'est ainsi qu'est née la programmation procédurale.
La POO est une autre étape dans la décomposition du travail global en composants plus simples.
La division du travail et, par conséquent, la mécanisation de la production de n'importe quoi ont donné naissance à la révolution industrielle, qui a conduit à l'industrialisation de l'humanité.
Faire à la main, c'est "écrire du code sans procédures".
Le convoyeur est une "écriture de code procédural", où de nombreux éléments du convoyeur sont dépendants des autres. En d'autres termes, la modification d'un élément peut nécessiter la modification d'un autre.
La "programmation OOP" est un pipeline dont la dépendance entre les éléments est réduite. En d'autres termes, un élément peut être remplacé par un autre et le pipeline risque moins de s'arrêter de fonctionner. Être capable de décomposer toute production en parties indépendantes, en introduisant des normes, etc. - est la fabrication orientée objet (et non la programmation).
La programmation elle-même est un cas particulier de production. L'approche OOP est une approche de principe pour produire n'importe quoi. Par conséquent, il est très étroit de parler de programmation. La POO a été appliquée avec succès AVANT son apparition dans la programmation.
J'en ai assez des Casanovas. Vous avez inventé un conte de fées et y avez cru vous-même (comme un enfant qui croit au Père Noël, pour l'amour de Dieu).
Je t'envie, Lech !
Très sérieusement. Eh bien, laissez-moi le droit à une petite hyperbole artistique...
Le nombre de mouvements corporels dans la procédure ci-dessus...
О ! Bien dit.
Entièrement solidaire.
L'effort corporel dans le code de procédure ci-dessus devra être plus important si des modifications doivent être apportées.
En principe, l'effort corporel en POO ne peut pas être moindre, puisque 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 possède déjà une interface, c'est-à-dire qu'il est proposé de faire une autre couverture, qui est essentiellement dépourvue 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 ?