Discussion :

[grafik.muzik]

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?

[buggen25]

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

[gorgonite]

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

as-tu fait beaucoup de procédural avant de t'avancer sur ce point ?

[Invité]

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#...)

[grafik.muzik]

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.

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?

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?

[kromartien]

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.

[Tommy31]

Aucun rapport : Perl est procédural et tu n'as pas besoin de savoir comment fonctionne un ordi pour programmer avec...

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.

[Just-Soft]

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.

[Melem]

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.

Bin comparons :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SortArray(MyArray); // Procédural impératif

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MyArray.Sort(); // OO impératif

Dans quel cas faut-il connaître l'implémentation et dans quel cas non ?

[Tommy31]

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
// procédural
SortArray(MyArray);

vs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
// objet
x.sort(MyArray)

[Melem]

Tu voulais sûrement écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x.sort();

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

1
2
sort(x);
sort(y);

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
x.sort();
y.sort();

[Tommy31]

Tu voulais sûrement écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x.sort();

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 :

Non, moi j'écris ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
x.sort( MonTableau )

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.

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.

[Melem]

Non, moi j'écris ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
x.sort( MonTableau )

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.

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 ?

[Graffito]

Je me demande, à l'inverse, quels sont les avantages de la programmation procédurale?

Tous les langages objets peuvent plus ou moins faire du procédural.
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.

[Tommy31]

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).

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
x.sort(MonTableau)

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
SortArray(MyArray);

elle est imposée.

C'est une différence très grande.

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 ?

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.

[Garulfo]

[...]
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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x.sort(myArray)

mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

method class::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

SortArray(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.

[gorgonite]

Le problème de ton exemple est que ce n'est pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x.sort(myArray)

mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

method class::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

SortArray(MyArray)

avec les modules de certains langages, on peut abstraire un peu plus, et rester en procédural

[Tommy31]

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 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.

@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.

La rigueur voudrait que je parle de comportement attendu (i.e. obéissant à un contrat) et de comportement implémenté.

Les contrats, les patrons etc. ne sont pas propre à l'OO je te ferais remarquer.

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 ?

Le problème de ton exemple est que ce n'est pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x.sort(myArray)

mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

method class::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

SortArray(MyArray)

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).

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.

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.

[kromartien]

En fait, la question originale était :

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?

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.

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é.

[gorgonite]

Dans les langages procéduraux, il n'y a pas la notion de signature, à laquelle différentes implémentations pourrait se référer, et dont, par conséquence on pourrait appliquer le LSP. C'est naturellement le cas des 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.

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