Discussion :

[mrjay42]

Bonjour à tous,

Il n'y a pas si longtemps on m'a posé une question "toute bête" à laquelle je n'ai pas su répondre :
"Quand on prends la théorie relationnelle et qu'on cherche un article fondateur, on peut lire les écrits de Edgar Frank Codd.
Ce qu'on peut lire sur le sujet est très précis.
En revanche, qu'en est-il de la programmation orientée objet ? Où trouver un texte fondateur "équivalent" aux travaux de Codd ?"

Si vous avez un début de réponse à cette question je suis preneur.
(des liens vers les ouvrages de référence seraient aussi appréciés )

Merci d'avance

[Davidbrcz]

Ici -> http://fr.wikipedia.org/wiki/Program...objet#Origines

[mrjay42]

Ici -> http://fr.wikipedia.org/wiki/Program...objet#Origines

Merci de ta réponse

Même si je connais déjà bien l'article de wikipedia sur la POO...
Je vais tout de même citer le passage qui me pose problème :

Toutefois, ses principes n'ont pas été formalisées et c'est au cours des décennies 1980 et plus particulièrement 1990 qu'elles ont été théorisées.

Cela signifie que l'objet est apparu "petit à petit" ?
Cela signifie que l'objet a d'abord existé d'un point de vue technique (du code quoi) avant même d'être formalisé et théorisé ?
Cela signifie que la nécessité de la POO s'est faite ressentir à un tel point que des implémentations de langages objets ont eu lieues AVANT toute formalisation ?!

Ça me parait vraiment étonnant !

[Davidbrcz]

Cela signifie que l'objet est apparu "petit à petit" ?
Cela signifie que l'objet a d'abord existé d'un point de vue technique (du code quoi) avant même d'être formalisé et théorisé ?
Cela signifie que la nécessité de la POO s'est faite ressentir à un tel point que des implémentations de langages objets ont eu lieues AVANT toute formalisation ?!

Je ne sais pas, je n'étais pas né ^^. Mais si on se réfère à cette autre page, la POO est venue avant par le coté pratique (décomplexifier les programmes) et a été théorisée dans les années 1990.

Ça me parait vraiment étonnant !

Pas moi, il y a beaucoup de machine technique (je pense en particulier à la machine à vapeur) qu'on savait construire et faire marcher sans la moindre théorie derrière (le début de la thermodynamique date en gros 1800, les machines à vapeur de 1700/1750)

[souviron34]

Cela signifie que l'objet est apparu "petit à petit" ?
Cela signifie que l'objet a d'abord existé d'un point de vue technique (du code quoi) avant même d'être formalisé et théorisé ?
Cela signifie que la nécessité de la POO s'est faite ressentir à un tel point que des implémentations de langages objets ont eu lieues AVANT toute formalisation ?!

Ça me parait vraiment étonnant !

Tout simplement parce que pour vous "POO" = classes + etc..


Nous en avons (très) longuement discuté dans un autre débat ici-même (je crois dans Débats, mais peut-être dans ce forum Langages)..

La notion "d'objet" est une notion standard, inhérente à toute réflexion, en particulier physique.

Or la quasi-totalité des "informaticiens" jusqu'au milieu des années 80 étaient des scientifiques, à part ceux évoluant dans le milieu financier/bancaire.

On peut alors distinguer 2 "pensées" :

• celle "bancaire" : des comptes, avec des clients, quelques calculs, et des transactions.. On a bien des "objets", et usage de Cobol marche très bien dans ce contexte.
  
  
• celle "scientifique" : des "objets", auxquels on fait subir un "traitement", pour obtenir un "résultat". Ceci peut très bien se faire en Fortran, en C, ou en Assembleur...

Dans un cas comme dans l'autre, les "classes" ou les "méthodes" étaient bien entedu utilisées, mais d'une manière "procédurale"..

Un exemple :

j'ai fait un programme de traitement d'images en 1982, en Fortran. Les images proviennent de différentes caméras , de différentes tailles et formats. Je veux pouvoir effectuer plusieurs opérations.

Mes "images" sont des tableaux (d'entiers par exemple), avec des "attributs" (non liés au sein d'une structure, qui n'existait pas encore dans les langages) mais stockés dans des tableaux indicés (dimensions, origines, noms, ..).

Mon programme est un programme de commande (style bash ou DOS) qui attend que l'utilisateur rentre une commande.

Ces commandes peuvent être "read", "write", "add", "substract", "multiply", "divide", "shift", etc etc, avec des paramètres (nom, delta, etc)

Ce programme est écrit en Fortran, et pour les parties "basses" évntuellement en assembleur.


J'ai donc bien une manipulation d'objets, avec une "conception orientée objet", bien que ni le langage ni la formalisation ne soient objet au sens d'aujourd'hui..




Ce que je veux dire, c'est qu'il n'y a pas d'opposition de fond entre une approche et l'autre..

Tout physicien ou chimiste ou scientifique en général pense "naturellement" en objet.



Comme l'avait mentionné quelqu'un (Garulfo) dans le débat référé ci-dessus, la différence dans la modélisation est que une approche non-objet (au sens d'aujourd'hui) s'articule autour de la fonctionalité, alors que l'approche objet actuelle s'articule autour des objets et de leurs relations/attributs.


En tant que physicien, j'ai toujours pensé en termes de fonctionalités.. Je veux faire un programme de traitements d'images, donc je tourne autour du traitement , les images sont les éléments du traitement.

Dans une approche "objet", on sera plus orienté sur "le traitement est attaché à une image".




Il faut donc distinguer la "pensée" ou "conception" objet, de la programmation et des langages objets..

[lepinekong]

Cela signifie que l'objet a d'abord existé d'un point de vue technique (du code quoi) avant même d'être formalisé et théorisé ?
Cela signifie que la nécessité de la POO s'est faite ressentir à un tel point que des implémentations de langages objets ont eu lieues AVANT toute formalisation ?!

Ça me parait vraiment étonnant !

Ca te paraît étonnant ? Ce qui me paraît étonnant c'est que ça t'apparaisse étonnant

C'est souvent comme cela que la science avance, c'est peut-être l'éducation abstraite et formelle en école d'ingénieur qui finit par faire croire le contraire (genre le prof vous démontre E=MC^2 comme si ça coulait de source et donc tout le monde aurait pu avoir le Prix Nobel, il oublie de vous apprendre le contexte de la découverte qui est la partie réellement intéressante: l'épistémologie. En fait le prof lui-même l'a appris comme ça d'un autre prof ...).

Il faut savoir que l'inventeur de Simula n'était pas informaticien, il voulait avoir un langage dédié à la simulation et donc l'approche objet lui semblait plus adaptée. Ca aussi c'est un des facteurs récurrents du progrès, c'est quelqu'un d'extérieur au domaine qui voit les choses sous un autre angle qui permet le "Leap Jump" (saut quantique en quelque sorte) parce que ceux qui sont dans le domaine ont des oeillères et se contentent de la routine ou défendent farouchement le status quo.

Je vous conseille la lecture de Henri Poincaré (grand père de la théorie du chaos 60 ans avant que le nom soit donné, co-découvreur officiel de la Relativité Restreinte en fait selon Polytechnique il avait écrit un papier avant Einstein) qui a écrit "La Méthode Scientifique" où il déplore que le grand public croit que les découvertes découlent de la logique pure ou qu'il suffirait de faire tourner un super ordinateur et toutes les découvertes en découleraient.

[mrjay42]

Je vous remercie pour vos réponses !


Si vous aviez l'amabiltié de me retrouver le débat cité plus haut, cela me serait très profitable.


@lepinekong : la formulation de mes questions était délibérément naïve, parce qu'il s'agissait de "vraies questions". Je suis allé au bout de ma naïveté afin d'obtenir des réponses adaptées à un interlocuteur naïf

En ce qui concerne l'épistémologie, je sens que je vais m'y intéresser de plus prés en ce qui concerne l'informatique et les autres sciences qui m'intéressent !

[souviron34]

Si vous aviez l'amabiltié de me retrouver le débat cité plus haut, cela me serait très profitable.
!

il y a 2 longues discussions :

comparaison objet-procédural svp

ou celle-ci -la plus complète, citée dans celle ci-dessus) :

Les avantages du procédural par rapport à l'orienté objet

dans laquelle un des posteurs a établit un post résumant très bien la situation :


http://www.developpez.net/forums/m3930485-61/

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

Mais tu sais,

[mrjay42]

Merci beaucoup d'avoir retrouvé la discussion

Merci aussi pour le conseil sur la fonction "rechercher"...Je suis un habitué des forums, et j'avoue tout de même avoir du mal avec celui de developpez.com, oserais-je remettre en question l'ergonomie du site ? hé ben, oui un peu !


Concernant la citation :
"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."
Dire ceci, c'est n'avoir rien compris à l'OO, à mon avis.
L'OO ne fait pas plus la part-belle aux données qu'aux traitements, les méthodes ne sont pas un ajout de dernière minute, elles ne sont pas là pour agrémenter un lot de données.
Ce qui est dit, pourrait être juste mais cela me semble basé sur une réflexion bien trop expéditive et partielle.

[souviron34]

Concernant la citation :
"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."
Dire ceci, c'est n'avoir rien compris à l'OO, à mon avis.
L'OO ne fait pas plus la part-belle aux données qu'aux traitements, les méthodes ne sont pas un ajout de dernière minute, elles ne sont pas là pour agrémenter un lot de données.
Ce qui est dit, pourrait être juste mais cela me semble basé sur une réflexion bien trop expéditive et partielle.

Je ne suis pas du tout d'accord, et c'est pour ça que j'étais entièrement en accord avec l'analyse de Garulfo :

Quand on parle de classes , d'instance, d'héritage, etc etc, de MCD, et de tout un tas de choses et de modélisations (UML, entités-relations, agents, etc), on est bien centré sur les objets et leurs relations..

Pour moi, physicien à la base, quand on me demande une architecture logicielle (ou même d'une partie), je commence à penser en arborescance de fonctionalités.

Ensuite, je réfléchis aux données : jusque-là, c'est une entité abstraite globale...

Et ensuite, éventuellement, je déduis - construis une généralité, un "objet" donnée type....


Mais le document que je présente et sur lequel je (et mon équipe) s'appuie est simplement un schéma fonctionnel, une suite de "traitements", les données venant simplement s'y adjoindre...


Cite-moi un exemple de POO (que ce soit langage, modèle, méthodologie) qui s'établit comme ça et je pourrais éventuellement envisager d'un possible recouvrement ....





Disons que si tout le monde prenait au pied de la lettre l'expression "Object Oriented Programming" je serais d'accord (ce que je défend un peu partout).

Malheureusement l'acception dans ce sens n'est pas l'entendement général, à cause des effets de mode, des langages objets, des marketings "OO", des méthodologies associées, etc etc...

[mrjay42]

Plusieurs éléments de réflexion font que je percute mieux désormais.

1. Je ne suis pas un "pur" informaticien
2. Mon bagage scientifique "pur" est relativement léger
3. J'ai pris le temps de lire ce que tu as expliqué et ça "sonne" mieux que ce que tu as mis en citation
4. Je suis un informaticien "récent" et habitué à ce que l'on appelle l'informatique de gestion (par opposition à l'informatique industrielle (?))

Au final, je capte un peu mieux et m'aperçois que les choses ne sont pas aussi noires/blanches que ce qu'on veut bien usuellement nous faire croire sur les forums ou en cours ou dans certaines articles.

Bref, je te remercie pour tes explications

[wiztricks]

La programmation procédurale est obligée d'utiliser des concepts objets pour arriver à construire des applications un peu conséquente.

Allez voir le code de X11, ou de GTK, c'est du C mais il y a des objets "pauvres" mais suffisants pour arriver à gérer la complexité du truc.

Ce qui montre l'extension du procédural dans l'objet, c'est le pouvoir ou la force du "verbe". Les verbes sont les méthodes qu'on applique à des entités. Si vous regardez une hiérarchie de classe, vous avez "en haut" les verbes partagées et la spécialisation (vers le bas) va de pair avec les données.

Ce n'est pas une structure très nouvelle: depuis les années 60 n'importe quel OS réalise ainsi l'API qui permet d'intégrer des pilotes de contrôleurs de périphériques.

Il n'en reste pas moins que le verbe, au sens actions supportées par, sont des attributs qui caractérisent les entités du domaine. Et tant qu'on se limite "à un domaine pas trop compliqué", procédural et objet se valent.

Dans une organisation "compliquée", nous allons avoir des entités telles que client, commande, produit, facture,... qui appartiennent souvent à des domaines différents... Il sera donc "normal" d'avoir des attributs/méthodes particuliers pour chaque "entités".

Mais prenons les entités et regardons les relations qu'elles ont entre elles... la nature du lien est en général le résultat d'une activité/processus métier "aidées" par une ou plusieurs applications.

Le langage UML est assez riche pour nous permettre de représenter cela. Mais nous ne sommes plus vraiment dans le monde de la POO - pris au sens gestion de la complexité d'une application, nous avons encore changé de niveau de complexité...
-W
PS: Soyez gentils! Il est présomptueux d'essayer de résumer les 40 ans d'évolution en quelques lignes. Mais les idées devraient être là.

[Kaeru No Uta]

Salut, je me rappelle qu'un prof avait parlé d'un article du magazine Byte datant d'août 1981: Design Principles Behind Smalltalk (attention c'est en anglais).

D'après ce que j'ai compris, ça définit des notions (objets, messages, polymorphisme, ...) utilisées dans le langage Smalltalk qui permet de programmer en termes de communication entre entités, et donc de conserver un mode de pensée naturel pour les humains.

[lepinekong]

Je vous remercie pour vos réponses !


Si vous aviez l'amabiltié de me retrouver le débat cité plus haut, cela me serait très profitable.


@lepinekong : la formulation de mes questions était délibérément naïve, parce qu'il s'agissait de "vraies questions". Je suis allé au bout de ma naïveté afin d'obtenir des réponses adaptées à un interlocuteur naïf

En ce qui concerne l'épistémologie, je sens que je vais m'y intéresser de plus prés en ce qui concerne l'informatique et les autres sciences qui m'intéressent !

Mais c'est très bien ! Je considère que l'étude vraie de la science c'est en fait l'épistémologie, mais je m'en suis rendue compte trop tard ... après l'école, quoique je me souviens d'avoir posé des questions également "bêtes" comme toi à mon prof de physique : "est-ce que la constance de la vitesse de la lumière est un postulat" comme il a pas su me répondre ça a dû me casser l'envie de devenir astrophysicienne (quelqu'un d'autres ici me comprend peut-être )

Le mieux pour aborder l'épistémologie c'est en fait d'étudier l'histoire, donc après la POO, si tu te poses la même question mais pour l'architecture MVC c'est ici:
http://lepinekong.fr/lengouement-pou...il-y-a-30-ans/

De manière générale il y a quelques bouquins à lire (sans se prendre trop la tête): celui que j'ai cité d'Henri Poincaré, celui de Bertrand Russell avec "La Méthode Scientifique en Philosophie" (ceci dit le Bertrand j'ai arrêté de l'admirer le jour où j'ai découvert d'autres écrits fascistes de lui mais bon on s'éloigne) et puis un bouquin très très drôle de Richard Feynman: "But You're Joking Mr Feyman" je pense qu'il a dû être traduit en français où il raconte les farces intellectuelles qu'ils faisaient à ses camarades qui montrent comment les étudiants apprennent les maths et la physique sans en fait comprendre (faut dire que vu comment c'est enseigné, une fois j'ai pris un bouquin de physique de début du 20ème siècle c'était bien mieux expliqué !).

Je pourrais m'étaler sur le sujet notamment en ce qui concerne les stats mais je crois que je vais finir par ennuyer, on est comme même sur un forum informatique, j'ai failli l'oublier

[souviron34]

Les gros cailloux

Un jour, un vieux professeur de l'École nationale d'administration
publique (ENAP) fut engagé pour donner une formation sur la
planification efficace de son temps à un groupe d'une quinzaine de
dirigeants de grosses compagnies nord-américaines. Ce cours constituait
l'un des cinq ateliers de leur journée de formation. Le vieux prof
n'avait donc qu'une heure pour "passer sa matière".

Debout, devant ce groupe d'élite (qui était prêt a noter tout ce que
l'expert allait enseigner), le vieux prof les regarda un par un,
lentement, puis leur dit : "Nous allons réaliser une expérience".

De sous la table qui le séparait de ses élèves, le vieux prof sortit
un immense pot Masson d'un gallon (pot de verre de plus de 4 litres)
qu'il posa délicatement en face de lui. Ensuite, il sortit environ une
douzaine de cailloux a peu près gros comme des balles de tennis et les
plaça délicatement, un par un, dans le grand pot.
Lorsque le pot fut rempli jusqu'au bord et qu'il fut impossible d'y
ajouter un caillou de plus, il leva lentement les yeux vers ses élevés
et leur demanda : "Est-ce que ce pot est plein?". Tous répondirent :
"Oui". Il attendit quelques secondes et ajouta : "Vraiment?".

Alors, il se pencha de nouveau et sortit de sous la table un
Récipient rempli de gravier. Avec minutie, il versa ce gravier sur les gros
cailloux, puis remua légèrement le pot. Les morceaux de gravier
s'infiltrèrent entre les cailloux... jusqu'au fond du pot.
Le vieux prof leva a nouveau les yeux vers son auditoire et
redemanda: "Est-ce que ce pot est plein?". Cette fois, ses brillants élèves
commençaient à comprendre son manège. L'un d'eux répondit :"Probablement pas!".
"Bien!" répondit le vieux prof.

Il se pencha de nouveau et cette fois, sortit de sous la table un
Seau de sable. Avec attention, il versa le sable dans le pot. Le
sable alla remplir les espaces entre les gros cailloux et le gravier.
Encore une fois, il demanda :"Est-ce que ce pot est plein?". Cette fois, sans
hésiter et en chœur, les brillants élèves répondirent :"Non!".
"Bien!" répondit le vieux prof.

Et comme s'y attendaient ses prestigieux élèves, il prit le pichet
d'eau qui était sur la table et remplit le pot jusqu'à ras bord. Le vieux
prof leva alors les yeux vers son groupe et demanda :"Quelle grande
vérité nous démontre cette expérience?"

Pas fou, le plus audacieux des élèves, songeant au sujet de ce
cours, répondit :"Cela démontre que même lorsque l'on croit que notre
agenda est complètement rempli, si on le veut vraiment, on peut y ajouter
plus de rendez-vous, plus de choses à faire".

"Non" répondit le vieux prof. "Ce n'est pas cela. La grande vérité
que nous démontre cette expérience est la suivante : si on ne met pas
les gros cailloux en premier dans le pot, on ne pourra jamais les faire
entrer tous, ensuite".

Il y eut un profond silence, chacun prenant conscience de l'évidence
de ces propos.

Le vieux prof leur dit alors : "Quels sont les gros cailloux dans
Votre vie?" "Votre santé?" "Votre famille?" "Vos ami(e)s?" "Réaliser vos
rêves?" "Faire ce que vous aimez?" "Apprendre?" "Défendre une cause?"
"Relaxer?" "Prendre le temps...?" "Ou... toute autre chose?"
"Ce qu'il faut retenir, c'est l'importance de mettre ses GROS
CAILLOUX en premier dans sa vie, sinon on risque de ne pas réussir...sa vie.
Si on donne priorité aux peccadilles (le gravier, le sable), on
remplira sa vie de peccadilles et on n'aura plus suffisamment de temps précieux
a consacrer aux éléments importants de sa vie.
Alors, n'oubliez pas de vous poser a vous-même la question : "Quels
sont les GROS CAILLOUX dans ma vie?" Ensuite, mettez-les en premier dans
votre pot (vie)"

D'un geste amical de la main, le vieux professeur salua son
auditoire et lentement quitta la salle.

[mrjay42]

Merci beaucoup à toi lepinekong pour ta réponse !
N'hésite pas à t'exprimer, personnellement je suis toujours intéressé par la démarche que les autres ont adopté pour s'approprier/explorer "le savoir"

Merci aussi à toi souviron34, pour cette 'anecdote' que je connaissais déjà, mais qui est toujours bon de relire de temps en temps !

[Tommy31]

La vrai histoire c'est :
Le prof prend une bière, la décapsule et la verse entièrement dans le bocal qui devait cette fois être finalement plein.

La morale est que, aussi bien remplie soit ton existance, il y a toujours de la place pour une petite bière...

[benwit]

Bonjour,

Je n'ai pas envie de polémiquer avec qui que ce soit parce que sous les mots, on à chacun quelque chose de bien particulier en tête. Je me rappelle d'une prof d'expression qui nous disait que derrière le concept de chien, certains "voient" un chiwava, d'autres un doberman ou un saint bernard. Tout cela restant bien entendu implicite et beaucoup pensant que leur vision est celle de l'autre, bonjour les incompréhensions.

Alors, vous pensez, avec un mot comme "objet", on est pas sorti de l'auberge ...


Pour ma part :

Je pense qu'on pouvait faire de la programmation orientée objet avant d'avoir des langages adaptés mais que l'usage de ceux-ci aide quand même l'implémentation.

Je pense également qu'une personne rigoureuse peut faire du bon travail avec une approche plutôt qu'une autre, que les approches sont différentes (procédurales, fonctionnelles, objets) et c'est tout. Je rappelle que le contraire de égal, ce n'est pas inférieur ou supérieur mais différent.

Je rejoins l'avis qui exprime que l'objet est plus orientée donnée dans la mesure où on est d'accord sur les faits :
- le procédural est plus orienté traitements (procédures, fonctions avec entrée sorties)
- un des apports de l'objet a été d'apporter l'encapsulation des données (et c'est en ce sens que c'est plus orienté donnée). En POO, il s'agit de regrouper la structure de données (état) au plus près des méthodes qui manipulent ces données (comportement) d'où cette notion d'objet.

Je recommande la lecture du livre de Bertrand Meyer (Conception et programmation orientées objets) qui est très didactique sur le sujet. C'est à défaut d'être la référence, une référence.

Face à un problème, j'ai grosso modo une approche descendante. J'image d'abord les entités et leur donne un nom et des caractéristiques (au sens de meyer) et voit les relations qu'elles peuvent entretenir entre elle. Bien sur, il y a plusieurs aller retour, une sorte de refactoring pour rendre les noms de ces caractéristiques les plus pertinentes possibles.
J'abouti alors à un ensemble d'interface qui spécifient les méthodes.
Ensuite, je passe à l'implémentation et selon les cas, je garde ou non l'interface si elle est utile.

[Oishiiii]

Pour revenir un peu sur la question de départ.

Quelle est la définition de la "Programmation Orientée Objet", mis à part: "c'est utiliser le concept d'Objet" ?

Plus précisément, peut-ont dire de manière objective qu'un langage de programmation soit plus "Orienté Objet" qu'un autre ?

Par exemple, il semblerait (je ne suis pas spécialiste) que le le C++ utilise de l'héritage multiple. Le Java ne gère pas l'héritage multiple, mais un héritage simple avec utilisation d'interfaces.
Ces différences sembles importantes. Mais pourquoi de telles différences ?
Lequel de ces langages respecte le plus une éventuelle "théorie Objet" - définie quelque part? - qui énumèrerait les règles à suivre pour un langage "OO" idéal ?

Ces questions sont peut-être un peu "bêtes" mais j'y pense.


PS: Second exemple: Il semblerait que de manière unanime, les développeurs considèrent le PHP comme étant moins "OO" que le Java. Pourquoi ?

[SpiceGuid]

En revanche, qu'en est-il de la programmation orientée objet ? Où trouver un texte fondateur "équivalent" aux travaux de Codd ?"

Le plus proche de ce que tu cherches est sans doute Conception et programmation orientées objet de Bertrand Meyer suivi de Design Patterns. Tout est dit dans ces deux ouvrages.

Les gros cailloux
...

J'aime bien ton histoire.
Et bien sûr je suis d'accord avec toi et avec la citation de Garulfo.

La morale de l'histoire c'est qu'il faut d'abord apprendre la programmation procédurale, la programmation modulaire et l'algorithmique, ce sont les gros cailloux et le gravier.

@Oishiiii
Tes questions semblent contenir un présupposé selon lequel la poo serait le porte-drapeau de la quête de perfection.

En fait la poo c'est surtout une bonne approche qui a percé au delà de toute raison parce qu'elle correspond bien à la démarche "liste de commissions" typique de la culture d'entreprise (cahier des charges, todo list, post-it,...).
Les objets c'est du concret qui parle à l'organisationnel dans l'entreprise (le mot classe a beaucoup moins de succès).
Le plébiscite sans fin pour la poo ne correspond plus à une étape de l'évolution du génie logiciel. L'industrie se fiche complètement des paradigmes, la poo est devenu une norme organisationnelle et elle va le rester. L'industrie ne voudra plus changer un corpus de pratiques qui colle aussi bien à sa sous-culture.

La voie de la perfection existe sans doute encore mais elle ne passe plus par la poo.