Qu'est-ce que le code OOP peut faire que le code procédural ne peut pas faire ? - page 3
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
Avec des projets à petite échelle, vous pouvez montrer que tout problème peut être décomposé en code procédural. Cependant, les choses deviennent beaucoup plus difficiles lorsque vous avez des bases de code de plusieurs millions de lignes avec des équipes de plus de 100 développeurs, plusieurs analystes d'affaires et architectes qui veulent tous apporter des modifications au "modèle" simultanément. Dans ces circonstances, le modèle "métier" est généralement défini dans un outil de conception comme UML et est accessible à toute l'équipe.
Le modèle métier contient à lui seul plus de 5000 classes. À partir de ce modèle métier, il existe des outils qui "génèrent" des classes pour le modèle objet, les interfaces SQL et les couches réseau, ce qui porte le nombre de classes de base à 15 000.
Pour cette discussion, je voudrais décomposer l'argument procédural contre la POO en trois "extensions" qui ont été ajoutées au procédural depuis les années 1960/1970
1) "Object Based" : les objets et le code sont encapsulés pour former des "structures" avancées qui peuvent également avoir des comportements.
2) "Class based" : les objets peuvent hériter les uns des autres et être organisés en hiérarchies.
3) "Orienté objet" : l'utilisateur peut définir des comportements "polymorphes" (méthodes ou interfaces virtuelles) au sein des hiérarchies de classes.
Il existe un argument selon lequel tout ce qui précède peut être mis en œuvre dans des langages procéduraux avec suffisamment d'effort, par exemple la plupart des boîtes à outils GUI dans les années 80/90 ont été créées en c et avaient ces caractéristiques, mais elles ne sont pas faciles à mettre en œuvre par le codeur occasionnel et ne sont pas vraiment applicables à cette discussion.
Donc, pour répondre à la question, pouvons-nous mettre en œuvre un projet de plusieurs millions de lignes avec 100+ développeurs sans utiliser les 3 caractéristiques de la POO ?
Mon opinion personnelle est qu'il est pratiquement impossible de livrer un projet à grande échelle sans 1) et 2) parce que sans un système "basé sur des classes", il est très difficile de transposer les structures de données et les comportements du monde réel dans le code d'une manière propre et concise. Et plus précisément, à mesure que la taille de votre projet augmente, ce qui commence par un "nous pouvons implémenter cela en c" devient une liste interminable de méthodes avec moins de structure qui deviennent plus difficiles à maintenir.
Les langages qui ne fournissent que les points 1) et 2) ne sont pas des langages entièrement OOP. Nous devrions donc nous demander si les "méthodes polymorphes (virtuelles)" sont vraiment nécessaires. Il s'agit plutôt d'un "peut-être" ou d'un "parfois", car le polymorphisme n'est pas toujours le bon outil pour résoudre un problème et peut compliquer excessivement la conception. Par exemple, lors de la modélisation de certaines structures de données qui correspondent à un magasin d'objets ou à une base de données SQL, l'ajout de comportements virtuels peut rendre le mappage des données plus difficile, mais lors de la définition de boîtes à outils ou d'API extensibles, l'utilisation d'une "interface" ou d'une classe de base avec des "méthodes virtuelles" est inestimable. Dans l'ensemble, je suis un grand fan du polymorphisme lorsqu'il est utilisé avec parcimonie et dans le bon contexte.
J'ai travaillé sur quelques bases de code "C" de plusieurs millions de lignes et sur plusieurs autres bases de code C++/Java/C# de plusieurs millions de lignes, et la plupart des bases de code "C" passent en "mode maintenance" après 5 ans parce que les développeurs ont peur de changer l'architecture car le code est trop fragile et les modifications entraînent souvent des mois de redéveloppement et de tests douloureux. En général, les projets orientés objet sont beaucoup plus résistants aux modifications et au remaniement.
Une instruction "if...then...else..." devrait faire l'affaire.
if...then...else n'est pas capable de coder des méthodes "virtuelles".
Il existe plusieurs implémentations du "polymorphisme" en "C" et la plupart d'entre elles utilisent des vecteurs de pointeurs de fonctions pour contenir les mappings nécessaires. Plus précisément, ces "vecteurs de pointeurs de fonction" doivent être définis pour chaque "type" que vous souhaitez modéliser dans la "hiérarchie". Bien entendu, le langage "C" ne prend pas directement en charge les hiérarchies et vous devrez donc résoudre ce problème également.
Si vous voulez vraiment entrer dans le sac de vers que sont les méthodes "virtuelles" implémentées en "C", vous pouvez sortir les boîtes à outils X-Window qui sont disponibles gratuitement dans chaque distribution Linux.
Windows doit bien sûr être légèrement différent et utilise des structures extensibles avec des identifiants de messages entiers, ce qui signifie que le comportement "polymorphe" est mis en œuvre via des instructions de commutation sur les identifiants. (c'est probablement la façon la plus sale de faire, mais cela vous permettra d'y arriver)
Êtes-vous d'accord pour dire que le système d'exploitation Windows offre une bonne interface graphique ? Pour autant que je sache, il est écrit en C. Un langage procédural, pas une programmation orientée objet.
Vous avez tort Dirk si vous pensez qu'un programme complexe ne peut être construit qu'en POO. Vous devriez plutôt expliquer pourquoi il est préférable de le coder en POO.
Le noyau de Windows est en "C" mais le noyau n'est qu'un petit composant de la base de code de Windows et une grande partie de la base de code de niveau supérieur est implémentée en C++ avec des interfaces externes de style "C" pour supporter plusieurs langages.
Même les anciens composants de l'interface utilisateur graphique de Windows mettent en œuvre leurs propres "comportements polymorphes", qui sont effectivement des "POO" mis en œuvre en "C". Par exemple, lorsque vous recevez un "Handle" en retour d'un contrôle GUI, vous obtenez une structure "C" extensible avec un comportement polymorphe disponible, c'est de la POO simplement enveloppée dans un ensemble laid de syntaxe "C".
Dire que Windows n'est pas une POO parce qu'il est écrit en "C" n'est pas totalement exact.
Je ne construirai pas une interface graphique en langage procédural pour prouver que vous avez tort. Mais je pourrais sans aucun doute.
D'ailleurs, il est également facile de coder du code illisible et beaucoup plus lent en POO, et comme vous le savez, la bibliothèque standard de Metaquotes en est une bonne preuve.
La POO étant beaucoup plus lente que le code procédural est un mythe complet. La raison pour laquelle de nombreux projets POO sont plus lents est qu'ils sont mal conçus. L'overhead pour un appel de fonction virtuelle est bien plus petit que ce à quoi on pourrait s'attendre, surtout avec les architectures actuelles de récupération de mémoire sur puce qui peuvent rechercher et exécuter en parallèle.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
Citation du lien ci-dessus : "Mais le coût d'un appel, quelle que soit sa saveur, est dominé par l'évaluation de ses arguments. Nous avons vu que les appels indirects, qu'il s'agisse de méthodes virtuelles de style C ou C++, sont intrinsèquement peu coûteux. Un appel à une méthode virtuelle n'est pas plus coûteux qu'un appel indirect utilisant un membre de structure (quelque chose->fonction(arg1,arg2)) donc considérer la fonction virtuelle comme incroyablement lente est juste mal informé."
Java peut être beaucoup plus lent que C++ parce que chaque élément de données encapsulé doit lui-même être une classe basée sur le tas, donc vous avez beaucoup plus de déréférencement d'objets. Cependant, même Java peut être exactement à la même vitesse que C dans les boucles et les opérations mathématiques de base.
Si vous comparez C et C#, il est vraiment très difficile d'écrire du code qui soit significativement plus rapide en C qu'en C#, même en incluant certaines des caractéristiques de la POO.
Si la bibliothèque standard de Metaquotes est lente, cela sera dû à 90% à la conception des fonctionnalités de la bibliothèque et aura très peu à voir avec les fonctionnalités OOP utilisées.
(A titre de comparaison, la bibliothèque standard de modèles C++ est plus performante que 95% des projets C jamais écrits).
...
Merci pour votre grande contribution.
Merci pour votre grande contribution.
Merci, et je ne me moquais pas de vous, c'est juste que vous êtes le seul à défendre l'argument procédural :)
Pas de soucis, je dois jouer mon rôle de "modérateur".
Bien sûr, ce serait bien de voir quelques exemples de ce dont vous parlez. Parler et taper, c'est bien pour les gens qui ont de l'expérience dans tout ça, mais je suis un étudiant visuel et pratique, merci de poster des exemples.
Je suis en train de me demander si je vais continuer à apprendre mql4, passer à mql5 ou simplement opter pour une autre plateforme.
Merci Alain d'avoir lancé ce fil de discussion. Ce forum en a vraiment besoin.
Vous vous attendez vraiment à ce que quelqu'un de professionnel poste une bibliothèque de compex, juste comme ça, comme une "preuve" ? ;) Je pourrais vous poster un lien vers quelque chose de prêt qui ne peut pas être vendu sur le marché ici, mais Alain va me donner un coup de pied si je le fais ;) Vous pouvez visiter mon profil et jeter un coup d'oeil à la photo du mur pour vous faire une idée ou m'envoyer un mail.
Une autre plateforme ? Vous ne trouverez pas d'autre plateforme avec un compilateur aussi puissant. Pas du tout.
@James Cater - merci beaucoup pour vos commentaires.
Vous vous attendez vraiment à ce que quelqu'un de professionnel poste une bibliothèque de compex, juste comme ça, comme une "preuve" ? ;) Je pourrais vous poster un lien vers quelque chose de prêt qui ne peut pas être vendu sur le marché ici, mais Alain va me donner un coup de pied si je le fais ;) Vous pouvez visiter mon profil et jeter un coup d'oeil à la photo du mur pour vous faire une idée ou m'envoyer un mail.
Une autre plateforme ? Vous ne trouverez pas d'autre plateforme avec un compilateur aussi puissant. Pas du tout.
@James Cater - merci beaucoup pour vos commentaires.