Salut!
Plusieurs discussions traitent des avantages de la programmation orientée objet. Je me demande, à l'inverse, quels sont les avantages de la programmation procédurale?
Salut!
Plusieurs discussions traitent des avantages de la programmation orientée objet. Je me demande, à l'inverse, quels sont les avantages de la programmation procédurale?
Le traitement procedural demande a lutilisateur de savoir tous les detail d'implementation c'est comme ci on devrait savoir ce qui se passe dans le moteur pour conduire un voiture. Par contre l'orienté objet ne te demande pas de savoir se qui se passe dans le moteur pour conduire une voiture
Moteur = implémentation
Tableau de bord = interface
Aucun rapport : Perl est procédural et tu n'as pas besoin de savoir comment fonctionne un ordi pour programmer avec...
Ce n'est qu'une question de paradigme. La façon dont tu perçois les choses, et comment tu vas t'y prendre pour élaborer ton programme.
Certaines tâches seront aisées à mettre en oeuvre et à coder en orienté objet, tandis que l'inverse est tout à fait vrai aussi. Idem pour la programmation fonctionnelle (Haskell, F#...)
On pourrait donc en conclure que c'est davantage une question d'école de pensée, ou de vision du programmeur? Et donc, on ne pourrait objectivement dire qu'un paradigme est meilleur que l'autre?kuzco: Ce n'est qu'une question de paradigme. La façon dont tu perçois les choses, et comment tu vas t'y prendre pour élaborer ton programme.
Et je désire déjà recentrer la discussion: quels sont les avantages concrets (une liste par exemple serait géniale) du procédural par rapport à l'orienté objet? Qu'est ce qui pousse certains programmeurs professionnels à utiliser le procédural alors que la plupart semblent parler de l'orienté objet comme plus avantageux?
En fait, je crois que la différence entre le paradigme objet et procédural est effectivement une question d'organisation du code.
Mais je me demande ce que signifie réellement programmation procédurale.
On peut tout de suite penser au C, ADA, Pascal et Basic, pour lesqels le paradigme de programmation « procédurale » semble bien marqué.
Cependant, par la suite, les langages Java, C++, par exemple, se sont dotés de paradigmes objets, tout en conservant un style de programmation très procédural à mon avis. Ces langages ont une syntaxe proche du C.
Tous les langages qui peuvent utiliser des sous-routines font effectivement de la programmation procédurale à mon sens.
Je trouve que c'est un paradigme qui touche de près ou de loin un bon nombre de langages qui permettent le paradigme fonctionnel ou objet.
Mais, en général, programmer dans un style strictement procédural va rallonger un programme, par rapport aux capacités d'abstractions des paradigmes fonctionnels et objet.
Tu peux facilement le constater, si tu programme en Python, et que tu privilégies une programmation strictement procédurale. Ne pas utiliser les caractéristiques fonctionnelles et objet de ce langage (la compréhension de liste par exemple) va te rendre la vie plus difficile que ce que permet le langage. Rendre un programme concis est souvent un avantage très important, car la lisibilité est meilleure, et le temps d'écriture beaucoup plus court.
En somme, je te conseille de t'initier à différents styles de programmation, via différents langages si tu veux te faire une idée de la chose. Plus le temps passe, et plus tu te rends compte des avantages que procure un langage très abstrait et évolué par rapport à autre chose comme le C, qui va avoir tendance à surcharger ta tâche de programmeur. Le tout est de trouver le langage le plus adapté à ton besoin.
Je pense que ce que voulait dire buggen, c'est que dans un contexte procédural, il y a une dualité entre la dénotation et l'implémentation.
Quand en perl on invoque la procédure de tri, on détermine également son implémentation (même si elle reste opaque au programmeur).
Ce n'est pas nécessairement vrai dans les langages à objets.
Salut;
le procédural est plus facile que l'orientée objet. mais une fois on a compris le principe de la POO on n'y songe même pas d'y revenir au procédural.
Bin comparons :
Code : Sélectionner tout - Visualiser dans une fenêtre à part SortArray(MyArray); // Procédural impératifDans quel cas faut-il connaître l'implémentation et dans quel cas non ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part MyArray.Sort(); // OO impératif
Dans les deux cas il y a forçage de l'implémentation, c'est à dire que la notation impose une implémentation.
Je répète, ce n'est pas nécessairement vrai dans les langages objets.
vs
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 // procédural SortArray(MyArray);
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 // objet x.sort(MyArray)
Tu voulais sûrement écrire :
Pour le deuxième cas où x peut être un tableau, une liste, etc. bref n'importe quoi. On peut faire pareil avec les langages procéduraux, grâce à la surcharge des fonctions (bon, ce ne sont pas tous les langages procéduraux qui le permettent ...). On peut donc par exemple faire :
Code : Sélectionner tout - Visualiser dans une fenêtre à part x.sort();
Peu importe ce que sont x et y, tout comme on peut faire :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 sort(x); sort(y);
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 x.sort(); y.sort();
Non, moi j'écris ceci :
x est l'instance d'une classe utilitaire portant l'opérateur de tri (on approche la notion de foncteur). MonTableau est l'argument à trier.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 x.sort( MonTableau )
x peut être implémenté de différentes façon et ce choix peut être opéré de différentes façons également, à la différence des langages procéduraux où le choix se fait par notation.
Là tu utilises une notation qu'on n'aime pas (pas qu'on peut pas) utiliser en procédural c'est tout. Je ne vois toujours pas en quoi un x.sort(MonTableau) cache mieux l'implémentation que sort(MonTableau). D'ailleurs on parle d'implémentation, pas de méthode ou de technologie. Que fait la fonction, ça il faut le connaître en procédural comme en orienté objets. Mais même dans ce cas, il est souvent indiqué avec quelles méthodes et/ou technologies a été développée la fonction. Sinon comment pourrait-on choisir entre deux bibliothèques qui fournissent les mêmes fonctionnalités ?
Tous les langages objets peuvent plus ou moins faire du procédural.Je me demande, à l'inverse, quels sont les avantages de la programmation procédurale?
La décision de faire du procédural plûtot que de l'objet revient alors au programmeur. Il va utiliser du procédural lorsqu'il jugera, au cas par cas, inutile la création et/ou l'instanciation d'un objet.
Derrière cette notation, tu as des notions qui te sont inaccessibles en procédural et qui jouent sur la détermination de l'implémentation. Ces notions sont les contrats et le principe de substitution. De là, en découle des patrons, d'architecture (par ex l'IoC) et de conception (par ex stratégie).
C'est l'une des pierre angulaire du paradigme.
Ainsi dans cette écriture :
l'implémentation concrète n'est pas exprimée. Alors que dans ton code :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 x.sort(MonTableau)
elle est imposée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 SortArray(MyArray);
C'est une différence très grande.
Mon propos ne porte pas sur la connaissance de la fonction. Il est utile de la connaître. Mais en orienté objet, il y a dissociation entre le contrat que remplit la fonction, et l'implémentation qui peut obéir à de nouvelles conditions.
En procédural tout autant. Ce que tu avances est le principe d'abstraction qui a d'abord été mis en pratique pour le procédural car l'orienté-objet n'existait pas.
Le paradigme de la programmation procédurale repose sur l'idée de décomposer le programme en sous-routine qui sont un découpage du traitement. Ceci n'est déjà pas relié à la programmation impérative. On peut faire du procédural dans du pure fonctionnel. Or, en général, on ne considère pas que le fonctionnel est plus proche de l'implémentation.
La seule différence entre le procédural et l'orienté-objet est dans la vision — duale, faut-il le préciser — du découpage des tâches : l'un procède en décomposant selon le traitement fonctionnel avant toute chose; l'autre procède en décomposant selon la complexité structurelle.
@Tommy31: Il faudra que tu m'expliques ce qu'est une implémentation abstraite. En effet, tu parles d'implémentation concrète: je suppose donc qu'il y en a une abstraite.
Les contrats, les patrons etc. ne sont pas propre à l'OO je te ferais remarquer. Certes, quand Meyer a introduit la programmation par contrat, par exemple, il l'a peut-être pensé objet a priori (étant donné qu'il pense toujours objet notre cher Bertrand ) mais le principe des contrats est très abstrait et parfaitement applicable à une vision procédurale.
Le problème de ton exemple est que ce n'est pas
mais
Code : Sélectionner tout - Visualiser dans une fenêtre à part x.sort(myArray)qu'il faudrait plutôt écrire. Dès lors, tu es flanqué d'un type et tu retombes sur une signature précise à la façon dont il me semble que tu voyais
Code : Sélectionner tout - Visualiser dans une fenêtre à part method class::sort (myArray)Un de mes mentors m'a toujours dit que la différence entre la POO et la PP c'est la différence entre (e f) et (f e). C'est dual.
Code : Sélectionner tout - Visualiser dans une fenêtre à part SortArray(MyArray)
Le principe d'abstraction dont tu me parles, c'est l'activité de taxonomie dans lequelle la procédure tient lieu de taxum dans les langages procéduraux, et la classe (ou le prototype) dans les langages à objets.
Ce dont je parles moi, c'est qu'en programmation procédurale, la notation induit l'implémentation et c'est un fait constatable dans la majorité des langages procéduraux. Mais ce n'est plus nécessairement vrai dans les langage à objets.
La rigueur voudrait que je parle de comportement attendu (i.e. obéissant à un contrat) et de comportement implémenté.
Je veux bien que tu me montre la transposition dans un langage procédural, je parles des design patterns. Les contrats, ca remonte à, heu, Hoare ?
Dans la majorité des langages procéduraux, il n'y a pas le moyen d'exprimer le lien entre une signature et différentes de ses implémentations dont on pourrait ensuite dynamiquement se référer.
Les modules dont parlait gorgonite sont un moyen, mais il me semble bien incomplet, de part son côté statique (j'ai un doute pour modula).
alors que c'est naturel dans les langages objets (je devrais dire à classes).
Il est possible, et ca été fait il me semble, de créer un isomorphisme entre le C++ et le C, mais ceci est rendu possible par le trait, certes très embryonnaire, fonctionnel du C (passage de fonction en argument) ainsi que les pointeurs (void*). Dans les autres langages, tu repasseras.
En fait, la question originale était :
Voilà, puisque la question est posée, je voudrai dire qu'elle semble biaisée. Je prends l'exemple de deux langages, qui sont ceux que je connais le mieux : Python et C.Plusieurs discussions traitent des avantages de la programmation orientée objet. Je me demande, à l'inverse, quels sont les avantages de la programmation procédurale?
En python, on peut faire de la POO aussi bien que de la programmation procédurale. Dans ce contexte, le programmeur va devoir faire un choix entre les styles programmation procédurale et orientée objet. Cependant, les facilités de ce langage pour le « tout objet » vont encourager les programmeurs à utiliser de la programmation objet, plutôt que de tout écrire en procédural.
Maintenant examinons l'exemple du C. Le C, qui encourage la programmation procédurale, peut tout aussi bien que le Python permettre de faire de la programmation orientée objet.
Cependant, en C, l'implémentation des objets est transparente, ce qui signifie qu'il faut déclarer les bonnes structures, avoir les méthodes d'initialisation qui vont bien, etc. Ce n'est pas une mince affaire de faire de l'objet en C, il faut sans cesse manipuler des pointeurs, des pointeurs sur structure, etc.
Je pense que la différence de temps entre Python et C pour faire de la programmation objet est dans une proportion de 1 pour 20. C'est énorme.
Ma conclusion : un simple programmeur, qui doit utiliser les outils à sa disposition, ne cherche pas à qualifier tel ou tel paradigme, mais à utiliser correctement les outils qui lui sont donnés pour réaliser l'objectif qui lui est fixé.
1) qu'appelles-tu un langage procédural ? il n'y a pas que C et Fortran dans la vie...
2) pour la notion de signature, comme l'a déjà signalé Garulfo, nombre de langages fonctionnels utilisent beaucoup le style procédural, et l'utilisation de module permet de faire beaucoup plus de choses que du simple C
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager