Bonjour.
J'aimerais que l'on m'explique les avantages de la programmation OO par rapport a la prog classique?
J'ai edudié le probleme (mal certainement) mais je n'arrive pas à trouver les supers avantages de celle ci!
Je dois certainement me tromper!
D'avance merci!
Re : POO avantages?
Bonjour,
Je n'aime pas beaucoup développer en POO, mais j'avoue que récupérer une classe toute faite développée par quelqu'un d'autre est une commodité appréciable que j'utilise parfois. Mais cela n'élimine pas le risque de bugs dans ces classes voyageuses.
Un langage procédural n'est écrit (en théorie) que pour une seule utilisation, alors qu'un POO va être réutilisable puisque générique, ce qui accélère le developpement.
Exemple avec une voiture :
procédural :
je prend un bas de caisse
j'y ajoute quatres pneus Michelin, puis
un moteur 90 chevaux TDI, puis
trois portes à vitres électriques,
je peint tout en rouge.
Voilà, super la caisse.
POO:
class voiture:
def __init__(self):
self.caisse=ajoute_caisse
def moteur(cylindré):
self.moulin=construct_moteur(c ylindré)
def vitre(élec=bool, couleur=bool)
self.vitre.electrique=elec
self.vitre.teinté=couleur
def couleur(teinte):
self.peinture=teinte
Ensuite tu instancies ta classe, càd tu la rends "vivante":
ma_caisse=voiture
ma_caisse.moulin(90ch)
ma_caisse.vitre(elec=True, couleur=False)
ma_caisse.couleur(vert_pomme)
voilà une jolie caisse, mais tu pourrais ensuite directement changer les paramètres sans devoir te retaper le code procédural. Ta classe est accessible, réutilisable et modifiable.
Sur une petite application, l'intérêt de la POO est probablement limité : la décomposition en appels de fonctions convient aussi bien si on fait les choses proprement.
Mais sur des applications complexes, de niveau professionnel, les avantages sont tellements nombreux qu'on imagine mal développer maintenant de grands logiciels sans POO.
Quelques avantages (liste non exhaustive) :
- introduit un niveau d'abstraction permettant de modéliser naturellement l'architecture de grandes applications, grâce en particulier au formalisme UML, ou à ce qu'on appelle les "design pattern"
- améliore la productivité : codes développés plus rapidement, plus fiables, partage naturel des taches
- facilite le développement et la diffusion de composants réutilisables
Encore que, contrairement à une idée reçue, le procédural se prête aussi à la réutilisabilité : on trouve bien toujours des bibliothèques de fonction en C ou en Fortran.
En programmation haut niveau, toutes les applications professionnelles récentes sont basées sur ce paradigme, et même en programmation bas niveau, pour le coeur d'un OS par exemple, l'approche peut être pertinente.
Un point important est que la POO n'est pas liée à un langage particulier, ni même à un langage implémentant nativement les concepts OO (héritage,polymorphisme,etc.) : on peut très bien faire de la POO en C ou en Fortran.
Et on peut très bien faire de la programmation procédurale assez sale en C++ en croyant faire de la POO parce qu'on a mis une ou deux classes dans son programme.
Langages objets répandus :
C++ : standard industriel, adapté au calcul scientifique, à la CAO et
modélisation 3D, etc.
Java : variante du C++, bien couplé avec Internet
Mais bon, tout ça est un peu du blabla. Les avantages apparaissent quand on commence à utiliser la POO sur un projet concrêt, au moment où on analyse le problème.
Salut,
en fait si tu veux, la majeur différence entre le C et le C++ est que en C tu peux créer des structures qui te définissent unu "objet", mais ces structures ne peuvent comporter que des variables (ou d'autres structures) mais pas fonctions. En C++, dans a structure (la classe), tu peux mettre a la fois des variables et aussi des fonctions, d'autres classes...
Ainsi, un objet peut avoir ses propres fonctions.
L'utilité en faisant ca, c'est que quand on utilise une classe, on a pas besoin d'importer dans le code les fonctions, puisqu'elles sont comprises dans la classe... A part ca, je suis pas assez calé en info pour voir plus d'utilité...
En fait, si : une structure C peut contenir un tableau de pointeurs de fonctions, qui est l'équivalent de la table des méthodes virtuelles des langages objets natifs.
C'est l'un des mécanismes qui permet de faire de la POO en C (ce n'est pas le seul), et en fait, les tous premiers compilateurs C++ commençaient par convertir la syntaxe C++ en C de cette façon, avant d'exécuter le compilateur C.
Certains systèmes de fenêtrage écrits en C utilisent aussi ce mécanisme et sont pourtant bien des systèmes objets.
Même si ce n'est pas très pratique, rien ne s'oppose à ce qu'on fasse de la POO en C ou en Fortran, ou même en assembleur.
Pour donner quelques exemples plus concrêts :
- Dans une application de type modeleur 3D, il est par exemple naturel d'associer classes et entités géométriques avec des opérateurs élémentaires, comme des transformations géométriques.
Une application 3D fortement interactive, dans laquelle des milliers d'entités coexistent et interagissent entre elles devient rapidement inextricable sans la notion d'objet.
- Dans une application de traitement d'image, on définira de façon évidente une classe "image" munie d'opérations élémentaires, mais aussi ce qu'on appelle des classes algorithmiques représentant des opérations de filtrage par exemple (qui ne doivent pas être incluses dans la classe image : erreur de conception courante...).
On peut aussi gérer facilement plusieurs types d'images grâce au mécanisme du polymorphisme, ce qui simplifie aussi le travail de documentation.
Liste bien sûr non exhaustive.
Mais, je le répète, ce n'est pas parce qu'on programme en C++ qu'on fait automatiquement de l'objet, et ce n'est pas parce qu'on programme en C qu'on n'en fait pas.
Justement tu (Lambda0) as mis le doigt sur le point que je ne comprenais pas : La reutilisation ! En effet ok une classe permet d'utiliser des methdodes deja ecrite tout comme une bibliotheque pour un langage procedurale alors je trouve que ce n'est pas un argument valable ...!
J'ai personnellement dus travailler avec du code ( java) qui appliquais ( je pense ) tous les pradigme OO ( polimorphisme etc) c'etait l'ENFER ! ca donnait des lignes en n'en plus finir du style:
Toto new( machin = titi ( new tata( parametre * 45) = new Tutu ( machin chouette) !
Bref! alors que si j'avais du travailler sur du procedural, je m'en saurais mieux sortie:
C'est pas evolué, peut etre, mais une ecriture unique pour une fonctionnalité unique, au moins on risque pas( ca n'engage que moi) de se mélangé !
Amicalement !
rep flyingman
Je ne suis pas un intégriste de la POO : mieux vaut un programme en mode "procédural" bien écrit qu'un programme en mode "objet" fait n'importe comment.
Pour une petite application, autant utiliser les méthodes qu'on maitrise bien.
La POO est incontournable pour des logiciels avec plusieurs centaines de milliers de lignes de code, des milliers d'objets en interaction, un comportement fortement dynamique, etc. et quand plusieurs personnes travaillent sur un même projet. Pour un logiciel de CAO par exemple.
Tu y viendras naturellement si le besoin s'en fera sentir, sinon, inutile de se compliquer la vie.
A+
je me suis attaqué à un logiciel de programmation RSA...
En C, t'es limité à 32 bits pour une variable...
J'ai fait ne structure pour faire du 2048 bits... Je n'ai pas pu finir mon programme car c'était du procédurale, ma struct et mes fonctions "associés" n'étaient pas facilement utilisables....
En POO tu fais une surcharge d'opérateurs...
en C il est toujours possible de faire:
struct segments{
sizeof_t pl;
sizeof_t ph;
}segments;
enum double_size_t{
struct segments seg;
void *pseg[4];
}double_size_t;
Mais par contre je ne suis pas sûre si l'inconvéniant de la POO ne serait pas plus la capacité du processeur.
Le processeur en mode réel à beaucoup de restriction, mais c'est le mode de démarage de nos PC.
En revanche en mode protégé, c'est très différent:
-voir : la gestion de la mémoire
- : l' interupt data table (idt), et la global data table (gdt).
Merci d'avoir répondu à une discussion de 2005
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
