Discussion :

[Garulfo]

Mais ce que je ne comprends pas, c'est la réelle différente entre procédural et objet... [..]

Mais il n'y en a pas de réelle différence !
Il y a une différence entre percevoir le monde d'après le paradigme objet et percevoir le monde d'après le paradigme procédural. Dans le premier cas tu vois le monde comme des objets qui communiquent entre eux pour résoudre une tâche. Chaque objet connait ce qu'il a à faire et comment il a à le faire. Il envoie des messages, à lui ou aux autres pour demander quelquechose. La paradigme procédural voit le monde comme une ensemble de fonctions qui collaborent. C'est une vision plus « mathématique » bien qu'il faille faire attention à ne pas faire un parallèle sans nuance. Résoudre un problème c'est appeler la bonne fonction qui elle-même appellera les autres qui lui sont nécessaires.

Est-ce qu'il y a opposition ? Non. Car les objets aussi doivent faire des actions et donc employer des procédures si on veut. Les fonctions elle s'appliquent sur des données et donc on retrouve des agrégats et d'autres données complexes qui peuvent être vu comme des « objets » aussi du monde. Ainsi, la procédure

Code :

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

1
2
int multiplier (int,int)

est un pendant à la méthode

Code :

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

1
2
int int::multiplier (int)

L'OO, c'est mettre les données en avant et décomposer le problème selon les relations (la complexité) entre ces données. Le procédural, c'est mettre les fonctionnalités en avant et décomposer le problème selon la complexité fonctionnelle. En pratique, on fait toujours un peu des deux. Les langages mettent juste plus l'emphase (attention anglicisme) sur l'une ou l'autre de ces points de vue en offrant une syntaxe et des propriétés qui s'y prêtent mieux. Mais finalement, on fait la même chose.

Certains vont te dire que l'un est meilleur que l'autre parce que plus « modulaire », « abstrait », « portable », « évolutif » etc. Ce ne sont que des points de vue personnel. Un bon code bien pensé d'un des deux paradigmes vaudra toujours mieux qu'un autre mal pensé, quelque soit le langage et le paradigme.

On revient donc sur ce qui a été dit — et note bien que le forum est rempli de ce genre de remarque — à savoir que l'idéal serait de choisir en fonction du problème et des moyens. En pratique, comme le mentionnait Luc, on a rarement le choix et on choisi un langage pour des raisons économiques, commerciales, organisationnel…

C'est un débat qui existe depuis l'avènement de l'OO dans les années 80. Il existe aussi avec tous les paradigmes qui semblent s'opposer. Et il n'y a aucune bonne réponse jusqu'à maintenant, que des préférences personnelles.

[souviron34]

..
L'OO, c'est mettre les données en avant et décomposer le problème selon les relations (la complexité) entre ces données. Le procédural, c'est mettre les fonctionnalités en avant et décomposer le problème selon la complexité fonctionnelle.
..

merci

Tu viens de m'éclairer sur le pourquoi j'ai tant de mal avec la "pensée" et la mode OO


Etant à la base physicien, je pense fondamentalement fonctionalité quand j'analyse un problème...

Et , m'étant frotté au cours de mes nombreux projets aux modèles Waterfall et autres (que tu connais à Sherbrooke : Macroscope), je viens de finir par comprendre le mouvement et la mode OO : cela vient des gens et des boîtes qui mettaient dans leurs specs les relations dans les BDDs.... (ce qui pour moi est une aberration...) en gros informatique de gestion et SSIIs du domaine....

(je me souviens d'un très très très gros projet des années 90 sur lequel j'ai travaillé, où l'architecte général m'expliquait son soft en me montrant le mur (tout le mur de son bureau) des relations dans la BD... et qui pour moi était du chinois.... Ainsi d'ailleurs que pour le marketing... )..

Voilà le fond.. Penser fonctionalité, au delà de l'aspect physique, est aussi beaucoup plus orienté Cahier des Charges, Utilisateur, et Marketing, bref interface extérieure au monde informatique.... Ce qui pour moi et beaucoup d'autres est plus naturel car l'info n'est qu'un outil...

Merci encore .. Je vais garder ce post en bookmark.. Quand j'aurais besoin d'arguments

[chaplin]

Bonjour,

La programmation objet permet de faire à la fois du procédural et de l'objet.
On peut très bien envisager une bibliothèque écrite en C (langage procédural) qui est utilisé dans
un programme objet ou toutes les entrées et sorties de la dll sont wrappés pour obtenir une interface.

De même, à l'intérieur d'une classe, il est tout à fait possible d'écrire le code de façon procédural.
La classe présentera une interface au monde objet à l'aide de ses méthodes et attributs.

Si on regarde un fichier Java, il ne comportera qu'une classe, de la même manière qu'un fichier en procédural
déclarera toutes les variables au début et les fonctions ensuite. Au fond c'est l'organisation des données au
sens des données de type propriété et les données de type méthodes qui est plus mis en avant avec la POO,
car les données (propriétés et méthodes) peuvent être visible uniquement au sein de la classe (privée), au travers
de l'héritage (protégé) ou visible des autres classes (public). Cette technique est d'autant plus pratique pour
éviter des confusions entre des variables portant le même nom comme dans des langages procéduraux.

En POO, il est plus facile de mettre des frontières pour la visibilité des méthodes et des variables. Autrement dit,
il est plus facile de décomposer le problème au prix de la maîtrise des process d'échange entre les objets.

[HerQuLe]

Ok je vois...


Par contre je n'ai toujours pas trop cerné la réponse a la question suivante:
"si on a le choix (aucune contrainte, et languages POO et proceduraux adaptés au projet), pourquoi choisir d'écrire un programme de manière 100% procédurale? Y-a-t-il un interet quelconque?"

[chaplin]

Je vois à priori deux interêts d'utiliser du procédural. D'une part dans les procédures stockées lorsqu'on manipule uniquement des données là ou parfois la POO est trop verbeuse et d'autre part le traitement des algorithmes car plus fidèle au niveau de la transcription, disons plus proche de la notation mathématique.

Je préfère:

Code :

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

Rect.width = Rect.width+X

à

Code :

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

Rect.width.add(X)

J'ai commencé la programmation avec Fortran, je ne vois pas ce qu'apporte la POO de plus dans le calcul scientifique.

Je dirais que plus il est fait usage d'un grand nombre de variables pour le calcul au sens mathématique, moins la programmation objet s'avère adéquat.

J'ai envie de dire que plus le problème est complexe, et plus la POO sera en mesure de traiter le problème de façon simple en le décomposant de façon atomique (ie les classes).

[Tommy31]

Je préfère:

Code :

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

Rect.width = Rect.width+X

Tu peux l'écrire comme tel en C# par exemple (properties).

[Luc Hermitte]

Il y a certes des ressemblances avec les diagrammes entité-relation, mais l'objet dispose avant tout de comportements.
Un objet sera une entité dont le rôle sera défini par ses responsabilités : les (au pluriel) services qu'il rendra. Bien souvent, on fera abstractions des détails d'implémentation (cet acte == encapsulation).
Une fonction/routine, c'est avant tout un seul service qui agit sur les paramètres ou une donnée d'état partagée (variable globale).

L'OO est une vision des choses. Après les langages peuvent fournir des facilités pour mettre en oeuvre tel ou tel autre aspect OO. En particulier pour tout ce qui touche au polymorphisme d'inclusion.

NB: je ne suis pas du tout dans les BdD, la gestion, ..., mais dans l'industriel (spatial pour être plus précis), et j'exploite l'OO pour ce que cela m'apporte, sans me mettre des œillères pour autant et considérer que si un bout de code n'est pas OO, alors il est mauvais.

[chaplin]

J'ai pris un mauvais exemple , je n'aurais pas du prendre Rect.width mais juste width. On va dire que je préfère la programmation "limitée" procédurale à la programmation objet pour les affectations.

Un autre exemple:

Code :

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

1
2
3
4
5
6
7
8
// style POO
Z= X.add(Y)

// Classique
Z= X+Y

// Fonction
Z= Add(X,Y)

Après c'est une question d'habitude, en y réflichissant bien.

Une différence fondamentale entre la POO et le langage procédural, c'est que le premier va exiger l'instanciation d'objet et par la suite la libéreration de la mémoire qui est fait de façon plus ou moins automatique en fonction des langages (ie garbage collector).

EDIT:

NB: je ne suis pas du tout dans les BdD, la gestion, ..., mais dans l'industriel (spatial pour être plus précis), et j'exploite l'OO pour ce que cela m'apporte, sans me mettre des œillères pour autant et considérer que si un bout de code n'est pas OO, alors il est mauvais.

Bonjour Luc et bonne année, je ne suis pas borné pour autant , si l'OO apporte un plus oui, sinon le style procédural peut aussi faire l'affaire. Je dirais qu'il s'agit d'en faire bon usage sans en mettre à toutes les sauces de façon abusive.

[Luc Hermitte]

De nouveau, ce n'est pas une question de POO, mais de sucre syntaxique.

Certains langages bridés se faisant passer pour super-OO-plus-que-les-autres ne supportent pas l'écriture mathématique. D'autres supportent l'écriture mathématique, et en plus l'opérateur sera aussi une fonction membre. Il ne faut pas se laisser berner par les limitations de certains langages pour en déduire celles des paradigmes.

EDIT: Oui, bonne année à tous. Pour avatar, il faudrait que je trouve des images de DRDs déguisés pour chaque occasion

[Garulfo]

merci

Tu viens de m'éclairer sur le pourquoi j'ai tant de mal avec la "pensée" et la mode OO


Etant à la base physicien, je pense fondamentalement fonctionalité quand j'analyse un problème...
[...]

J'ai eu le même problème au début. Mon background de mathématicien m'a toujours poussé vers l'approche fonctionnel et procédural.

[Garulfo]

[...]
L'OO est une vision des choses. Après les langages peuvent fournir des facilités pour mettre en oeuvre tel ou tel autre aspect OO. En particulier pour tout ce qui touche au polymorphisme d'inclusion.[...]
j'exploite l'OO pour ce que cela m'apporte, sans me mettre des œillères pour autant et considérer que si un bout de code n'est pas OO, alors il est mauvais

De nouveau, ce n'est pas une question de POO, mais de sucre syntaxique.

Certains langages bridées se faisant passer pour super-OO-plus-que-les-autres ne supportent pas l'écriture mathématique. D'autres supportent l'écriture mathématique, et en plus l'opérateur sera aussi une fonction membre. Il ne faut pas se laisser berner par les limitations de certains langages pour en déduire celles des paradigmes.

On est définitivement en accord toi et moi -_-
J'aime notamment ton passage sur les œillères. Il faudrait que les jeunes informaticiens et les étudiants en informatique en prennent de la graine : arrêtez de croire que tout s'arrête à telle technologie, tel langage, tel technique ou tel paradigme. Sachez garder votre esprit prompt à utiliser autre chose comme point de vue !

[el_slapper]

On est définitivement en accord toi et moi -_-
J'aime notamment ton passage sur les œillères. Il faudrait que les jeunes informaticiens et les étudiants en informatique en prennent de la graine : arrêtez de croire que tout s'arrête à telle technologie, tel langage, tel technique ou tel paradigme. Sachez garder votre esprit prompt à utiliser autre chose comme point de vue !

amen.

sauf que ça ne se limite pas aux jeunes. J'ai croisé un type, hyper compétent, auprès duquel j'ai appris plus en 3 semaines qu'auprès de n'importe qui en 1 an, mais pour qui tout ce qui n'était pas grand système n'était qu'infamie perpétuellement en panne. J'aime le grand système et je pense qu'il a plein de qualités ignorées des djeunz, mais pour faire une interface web, bof

[millie]

J'aime le grand système et je pense qu'il a plein de qualités ignorées des djeunz, mais pour faire une interface web, bof

Comment ça ?
Sur z/OS, il y a le serveur d'application d'IBM Java EE qui tourne dessus (WAS) qui permet de faire tourner des applications Web.(et WAS a plein de bibliothèques pour faire appel à des fonctionnalités se trouvant sous z/OS (appel de procédure cobol...)) => ce qui permet d'ailleurs de faire une IHM Web avec du code métier en cobol ou autres.

[souviron34]

J'aime le grand système et je pense qu'il a plein de qualités ignorées des djeunz, mais pour faire une interface web, bof

Je dirais comme millie :

Comment ça ?
Sur z/OS,
..

• Mosaic et Netscape, ancêtres de tous les navigateurs et du Web, sont basés sur Unix, VMS, et des gros systèmes.
  
• KConqueror ou Firefox sur Linux tournent sur des systèmes *nix...
  
• Les serveurs asynchrones ne sont apparus que très recemment (< 7 ans) sur Windows...

[alex_pi]

Ah, rien de tel qu'un petit troll quand on bloque sur un problème et qu'on veut se changer les idées

Je suis globalement d'accord avec la définition de Garulfo pour l'opposition entre "orienté objet" et procédural, à savoir que le premier est "guidé par les données" et le second "par les actions".
Là où je suis moins d'accord, c'est quand il dit que les deux sont duaux, puisque pour le procédural, on fait (f e) en appelant une procédure sur un objet, et dans l'autre on fait (e f) en appelant la procédure d'un objet.
Il faut se souvenir qu'en objet, un appel de méthode n'est pas un appel de fonction comme les autres. C'est un envoi de message (le fait qu'en C++ toutes les méthodes ne sont pas "virtuelles" de base ne contredit en rien ce que je viens de dire. C'est juste une quête d'efficacité qui fait que le langage s'éloigne de la "pureté" du paradigme). On envoie à l'objet un message lui disant qu'on veut qu'il fasse une certain action. Cette action peut être simplement de nous donner sa vitesse, ou de se trier, ou encore de détruire le monde. Dans tous les cas, on n'a nul besoin de savoir ce qu'est notre objet, juste qu'il est capable de répondre à notre demande.
En procédural en revanche, il faut savoir quel objet on a sous la main, pour pouvoir l'ouvrir, regarder ce qu'il y a dedans pour voir comment on va effectuer l'action que l'on veut.

Un exemple plus que classique est celui d'un conteneur. Supposons que je veuille avoir un conteneur, dans lequel je peux ajouter des éléments, que je peux pouvoir trier, et enfin, je veux itérer sur son contenu. Dans certain cas c'est une liste, ou une file, ou un tableau.
En procédural, quand je reçois un tel conteneur, il faut que je découvre de quel type il est pour pouvoir appeler la bonne fonction de tri dessus (tri_tableau, trie_liste, etc) alors qu'en objet, j'envoie juste un message disant "trie toi" à mon objet. Il y a dans le modèle objet ce que l'on appelle pompeusement un "polymorphisme de sous typage" (en moins pédant, c'est en gros le fait qu'on a de l'héritage, même si théoriquement ça n'a rien à voir ) qui n'est pas naturellement dans le paradigme procédural.

En revanche, il faut quand même souligner que les deux paradigmes n'ont pas de raison d'être exclusif. Quand je suis en train d'écrire ma méthode de tri pour ma liste, je vais la séparer en procédure (par exemple "couper ma liste en deux", "trier les sous liste", "fusionner les listes triées"). Donc il me semble qu'on fait forcément du procédural local

[Luc Hermitte]

tri(liste), tri(tableau) et liste.tri(), tableau.tri() ne sont que ces conventions d'écritures qui expriment exactement la même chose.

Avec votre vision syntaxique des passages de message vous vous excluez le dispatch multiple (polymorphisme sur plusieurs objets à la fois), et le typage du second ordre (si j'ai bien compris de quoi il s'agit)

[alex_pi]

tri(liste), tri(tableau) et liste.tri(), tableau.tri() ne sont que ces conventions d'écritures qui expriment exactement la même chose.

Justement pas dutout !
Quand j'écris l.tri(), je n'ai pas besoin de savoir si l est une liste ou un tableau, juste que c'est un objet avec une méthode tri. En revanche, si j'écris tri_liste(l), il faut que je sache que l est une liste pour savoir comment le trier. (Et qu'on ne vienne pas me dire qu'il suffit que la fonction tri attende un triable et appelle ça méthode tri, parce que là c'est de l'objet mal utilisé !).

Un exemple qui parle peut être plus serait celui d'éléments graphique "affichable". Si j'ai des carrés et des ronds, en procédural, il va me falloir une fonction affiche_carre et une fonction affiche_rond et il faudra que je sache initialement laquelle appeler, alors qu'en objet, il suffit que mes carrés et mes ronds aient tous les deux une méthode afficher que je peux appeler "aveuglément".

C'est profondément différent.

[gorgonite]

Un exemple qui parle peut être plus serait celui d'éléments graphique "affichable". Si j'ai des carrés et des ronds, en procédural, il va me falloir une fonction affiche_carre et une fonction affiche_rond et il faudra que je sache initialement laquelle appeler, alors qu'en objet, il suffit que mes carrés et mes ronds aient tous les deux une méthode afficher que je peux appeler "aveuglément".

c'est là qu'on retombe dans la pensée "procédurale, mais sans modules"

[Luc Hermitte]

J(Et qu'on ne vienne pas me dire qu'il suffit que la fonction tri attende un triable et appelle ça méthode tri, parce que là c'est de l'objet mal utilisé !).

Justement si.
Pourquoi serait-ce de l'objet mal utilisé ?
Vous vous attachez trop aux conventions d'écriture. C'est un détail d'implémentation propre à chaque langage, et sans la moindre importance.

Que l'on écrive obj.operation(), (operation obj), ou operation(obj), il n'y a aucune différence.

[alex_pi]

c'est là qu'on retombe dans la pensée "procédurale, mais sans modules"

Euh non. Même avec module, tu ne peux pas avoir une fonction qui attends un truc "imprimable" et qui l'imprime, sans se préoccuper de ce que c'est. En OCaml, tu as les objet (ou les types unions et une grosse fonction de dispatche dynamique) et en haskell les type class. Par contre les modules n'y changent rien.