Discussion :

[goodpz]

Dans pas mal de langages la propriété qui fait qu'on va faire de "l'Objet" est dû à un passage automatique et transparent dans les méthodes membres d'une référence vers une "structure" contenant des données. C'est le self de python, le this caché du c++ ou encore le context en javascript. On peut simuler ce comportement avec des langages purement procéduraux (cf le post de kromartien juste au dessus).

De ce point de vue la, la POO reste très procédurale dans ses fondements. On va vraiment faire de la POO quand on tire partie de la notion de polymorphisme ou le principe de substitution de Liskov.

La programmation fonctionnelle repose à mon sens sur un paradigme nettement plus détaché que ne le sont POO et procédurale.

[Tommy31]

1) qu'appelles-tu un langage procédural ? il n'y a pas que C et Fortran dans la vie...

Un langage à trait impératif, que je restreindrais aux langages à typage statique et exposant cet unique paradigme.

Donc : Ada 83, Pascal, Fortran, C, VB par exemple...

2) pour la notion de signature, comme l'a déjà signalé Garulfo, nombre de langages fonctionnels utilisent beaucoup le style procédural,

C'est une abération

et l'utilisation de module permet de faire beaucoup plus de choses que du simple C

Certes.

[gorgonite]

Un langage à trait impératif, que je restreindrais aux langages à typage statique et exposant cet unique paradigme.

Donc : Ada 83, Pascal, Fortran, C, VB par exemple...

c'est très restrictif

[Tommy31]

Tu voulais que je rajoute caml ?

[gorgonite]

Tu voulais que je rajoute caml ?

pas forcemment, mais que tu évites de dire que tout ce qui a été trouvé depuis 25 années en matière de langage informatique ne doit pas être pris en compte même si ça peut s'appliquer au paradigme procédural

[Tommy31]

Je définissais simplement les hypothèses dans lesquelles j'avais fait mon propos, en première réflexion.

Mais ok pour ouvrir.

[Garulfo]

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

Bon rapidement... obéir à un contrat n'a rien de propre à la programmation objet. La programmation par contrat remonte à Meyer. C'est lui qui a inventé le principe dans un article du milieu des années 80 (http://se.ethz.ch/~meyer/publications/ cf P35). Il a d'ailleurs déposé un trademark sur le terme pour Eiffel. Mais il se base, c'est vrai sur les travaux de Hoare.

Et qu'est ce qui empêche dans les langages procéduraux de faire des design patterns ? Les schémas sont apparus à la fin des années 70 pour aider à l'architecture des programmes qui étaient bien sûr écrit en procédurale à cette époque.

J'ai l'impression que tu parles de l'implémentation des langages. Alors certes, il n'existe pas de langage procéduraux à ma connaissance qui implémente dans leurs outils ce qu'on trouve pour eiffel par exemple. Mais le principe de programmation par contrat peut quand même s'appliquer à des langages procéduraux. Ce n'est pas antinomique. D'ailleurs, on peut bien faire « de l'objet » dans le paradigme procédural et des procédures dans le paradigme objet.

Tu as une vision très limitée du procédural. C'est un paradigme plus large que juste : impératif, à typage statique. Comme tout paradigme c'est très ouvert et n'impose que quelques points très « philosophique » finalement.

Finalement pour la dualité des deux paradigmes, je repasserais par le Scheme/Lisp qui permet d'implémenter les deux façons de faire. La dualité saute au yeux quand on a exactement la syntaxe dont je parlais, puisque souvent un objet est une fonction dans ces implémentations et que (o m args) exécute plus ou moins (m o args).

Il me semble que tu limites l'analyse aux langages, au lieu de voir le paradigme. Alors, oui si on regarde les langages ton analyse tient debout. Mais si on regarde les paradigmes tu es trop restrictif.

[Graffito]

N'oublions pas que l'objet est une "sur-couche" du procédural.

Donc on peut, si on le veut, recréer tous les comportements objets avec du procédural.

Les compilateurs/interpréteurs orientés objets apportent simplement une facilité pour coder de tels comportements. Toutefois, cet apport est tel qu'ils en arrivent à modifier notablement les habitudes de conception et d'implémentation.

[Garulfo]

N'oublions pas que l'objet est une "sur-couche" du procédural. [...]

Humm si tu parles de C/C++ tu fais une erreur. C'est faux maintenant. Si on regarde Smalltalk, je vois mal où tu vois la « première couche » aussi. Si tu parles d'un point de vue paradigme c'est faux aussi: quand je parlais de dual c'est qu'il n'y a pas de première ou seconde couche, mais deux manières de voir complémentaire.

C'est vrai qu'historiquement cela a ressemblé à ça, mais ce n'est pas une bonne façon de voir.

[kromartien]

Humm si tu parles de C/C++ tu fais une erreur. C'est faux maintenant. Si on regarde Smalltalk, je vois mal où tu vois la « première couche » aussi. Si tu parles d'un point de vue paradigme c'est faux aussi: quand je parlais de dual c'est qu'il n'y a pas de première ou seconde couche, mais deux manières de voir complémentaire.

C'est vrai qu'historiquement cela a ressemblé à ça, mais ce n'est pas une bonne façon de voir.

Les paradigmes tiennent la place qui est la leur dans la programmation, mais, basiquement, le programmation en langage assembleur est « procédurale » il me semble. On fait des sauts à l'adresse de la mémoire code pour telle ou telle sous routine qui modifie tel registre, l'appel est itéré tant de fois, etc.

Donc, on peut tout de même dire, en gros, que n'importe quel paradigme est une surcouche à la programmation procédurale. N'êtes vous pas d'accord ?

[Graffito]

Humm si tu parles de C/C++ tu fais une erreur. C'est faux maintenant.

Qu'est-ce qui empêche de manipuler en C des objets C++ , à partir du moment ou on connait l'implémentation objet faite par le compilateur ?

Ce que je veux dire, c'est qu'un langage procédural permet de créer et utiliser des "objets" parce qu'à la base un objet n'est que pointeurs et structures.

[hamza_bba]

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.

absolument oui, ce que vous avez dit

[Tommy31]

Tu as une vision très limitée du procédural. C'est un paradigme plus large que juste : impératif, à typage statique. Comme tout paradigme c'est très ouvert et n'impose que quelques points très « philosophique » finalement.

Ce n'est pas parce que je l'occulte que je l'ignore.

Finalement pour la dualité des deux paradigmes, je repasserais par le Scheme/Lisp qui permet d'implémenter les deux façons de faire. La dualité saute au yeux quand on a exactement la syntaxe dont je parlais, puisque souvent un objet est une fonction dans ces implémentations et que (o m args) exécute plus ou moins (m o args).

Je connais bien cette écriture mais elle ne rend pas compte du mécanisme (je dirais presque la turpitude) dont les langages objets opèrent, en particulier la virtualité de la fonction m.

Il me semble que tu limites l'analyse aux langages, au lieu de voir le paradigme. Alors, oui si on regarde les langages ton analyse tient debout. Mais si on regarde les paradigmes tu es trop restrictif.

On est dans le forum langage non ?

Ce que je veux dire, c'est qu'un langage procédural permet de créer et utiliser des "objets" parce qu'à la base un objet n'est que pointeurs et structures.

nope, tu as l'identité (le pointeur), l'état (la structure) mais il te manque le comportement, c'est à dire le jeu de fonctions qui s'y appliquent. Et là, y'a une petite subtilité de sélection qui rendent les choses un peu moins sympathiques.

[millie]

nope, tu as l'identité (le pointeur), l'état (la structure) mais il te manque le comportement, c'est à dire le jeu de fonctions qui s'y appliquent. Et là, y'a une petite subtilité de sélection qui rendent les choses un peu moins sympathiques.

Avec des pointeurs de fonctions, je ne vois pas trop le problème en fait.

[gorgonite]

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.

j'ai un ENORME doute sur le fait que la majorité des personnes utilisant la POO connaissent le paradigme procédural, voire maitrise correctement la POO... il n'y a qu'à voir la qualité moyenne d'un code Java est entreprise pour s'en faire une idée

Ce n'est pas parce que je l'occulte que je l'ignore.

donc on peut en déduire que toute ton argumentation est potentiellement mensongère ?

On est dans le forum langage non ?

on est dans un forum de développement et sur un forum "général"... donc les paradigmes de programmation sont aussi importants que les langages dans ce débat

[SpiceGuid]

Personnellement j'ai beaucoup joué avec Oberon System 3 qui est un système de composants graphiques (comparable à Smalltalk) écrit dans un langage procédural, typé statiquement, mais dont le style et les potentialités recouvrent toutes les possibilités qui sont traditionnellement présentées comme étant des apports du paradigme objet.
Les classes y sont implémentées comme des enregistrements dont les champs sont des procédures.

En fait c'est encore plus flexible que la POO, si tu le souhaites tu peux modifier une 'méthode' dynamiquement, il suffit de remplacer la procédure concernée par une autre qui a la même signature.

Par contre je t'accorde que ça n'est pas précisément cette manière de faire qu'on appelle couramment le style procédural.

[Garulfo]

Qu'est-ce qui empêche de manipuler en C des objets C++ , à partir du moment ou on connait l'implémentation objet faite par le compilateur ?[...]

Je ne parlais pas de ça. Je disais que si tu penses à C/C++ en disant que les objets sont une surcouche, c'est faux. C'était vrai.

[Garulfo]

[...]
Je connais bien cette écriture mais elle ne rend pas compte du mécanisme (je dirais presque la turpitude) dont les langages objets opèrent, en particulier la virtualité de la fonction m.[...]

Des illustrations ? parce que je ne vois toujours pas en quoi quand tu veux faire un tri dont l'algorithme est établi, le fait de faire de l'objet rend l'implémentation moins contraignante.

[Tommy31]

Des illustrations ? parce que je ne vois toujours pas en quoi quand tu veux faire un tri dont l'algorithme est établi, le fait de faire de l'objet rend l'implémentation moins contraignante.

Code :

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

1
2
3
4
List list; // une liste à trier
SortInterface sortFunctor = SortFactory.getAdequateSortFunctor() // implémentation occultée

sortFunctor.fn( list ); // L'appel n'induit pas l'implémentation

J'attends l'équivalence en un langage procédural de ton choix.

[gorgonite]

J'attends l'équivalence en un langage procédural de ton choix.

merci d'ajouter les signatures des méthodes utilisées, voire les héritages / interfaces en jeu... car a priori, je peux écrire du code objet qui ressemble à cela et qui ne compilera pas, ou pire qui ne sera pas du tout modulaire