Le concept de l'orienté objet

C'est un peu à cause de moi si ce sujet existe, donc il me faut bien y répondre 

Je trouve dommage que l'historique soit aussi bref. Même s'il n'y a pas nécessairement grand-chose à dire, je serais curieux de savoir quelle a été la réflexion des deux Norvégiens (dont je ne mettrais même pas le nom entre parenthèses, ils sont tout de même à l'origine de ce qui est présenté ) : ce qui les gênait dans leur façon de programmer, ce qu'ils ont eu comme premières idées, bref, le cheminement du procédural à l'objet — s'il y a moyen de trouver ces informations, évidemment.

Pour l'extrait de présentation "La POO", je trouve que les réponses aux questions sont très brèves, elles aussi. "La POO est une manière de programmer." J'ai bien peur que le lecteur le sache déjà… Ce qu'il aimerait savoir (et il "pose la question", d'ailleurs), c'est en quoi elle se démarque des autres. Les questions qui vont servir de fil rouge pour l'extrait sont toutes posées ensembles, pourquoi ne pas y répondre sans ajouter de titres ? L'enchaînement et l'explication permettraient d'être moins abrupte qu'avec ces titres, qui coupent parfois en très petits bouts l'extrait, à mon avis.
Aussi, j'éviterais de parler des "langages les plus communs", "les plus connus", etc.. Dites plutôt que "parmi les langages qui utilisent l'orienté objet, on peut trouver…", qui est plus neutre, et qui donne donc moins l'impression de discriminer ni d'autres langages qui pourraient être dans la liste, ni ceux qui ne permettent pas l'orienté objet.

Si vous posez des questions, comme après votre exemple en JAVA, mettez-en toutes les réponses, sans quoi les lecteurs peuvent ne pas comprendre où vous voulez en venir. La dernière question, notamment : mettez quelque chose comme « On a trois fois plus de lignes de code en procédural qu'en orienté objet !¹ »
Notez que certains pourraient aussi croire que vous vous fichez d'eux s'ils n'arrivent pas à voir ce que vous voulez leur faire voir…

Pour la partie "Les objets", je ne citerais pas PHP comme l'un de ceux qui utilisent le destructeur. L'utilisation de celui-ci dans ce langage me paraît être bien moins importante qu'en C++, par exemple.
Aussi, si vous comparez les objets IRL et les objets en programmation, mettez les deux exemples. Vous parlez de la voiture avec ses attributs et ses fonctions, parlez donc de la classe voiture avec ses propriétés et ses méthodes, cela vous permet de mieux parler de ces dernières et de créer le parallèle directement. Un lecteur pourra ainsi mieux se représenter la chose qu'en tombant sur le mot méthode (mis en gras plus loin, donc c'est important) au milieu du texte.
En parlant de gras, n'hésitez pas non-plus à l'utiliser la première fois que vous utilisez un terme important, pour autant que ce terme soit expliqué. Utilisez l'italique si vous avez des notions importantes qui sont reprises dans l'explication d'un nouveau terme important.

Là, la question a été changée, et l'enchaînement n'est plus terrible 

Je n'ai plus trop de temps maintenant, je reviendrai par ici éditer ce message s'il n'y a pas eu de réponses ou en créer un autre le cas échéant.

Edit

Si si, je suis revenu, mais les messages suivants contiennent ce que j'aurais ajouté 

Salut
Quelques remarques rapides au passage, j'essayerais de développer plus tard:
Je trouve que tu ne parles pas assez des concepts et que tu vas un peu vite vers l'implémentation (constructeur, classe abstraite,....). Il faudrait plus insister sur les concepts-clé de l'OO, décrits dans cet article par exemple: http://fr.wikipedia.org/wiki/SOLID_%28informatique%29

"Le but de la POO est simple, aller plus vite, pouvoir faire plus en écrivant moins.": là tu laisses penser que l'OO, c'est juste du code, alors que c'est surtout de la conception, de l'architecture.... On peut très bien penser objet, même avec un langage non objet.

Tu pourrais aussi développer la partie sur l'héritage multiple, et en quoi la notion d'interface permet de régler ces problèmes: http://fr.wikipedia.org/wiki/Probl%C3%A8me_du_diamant

Dans les années 60, il existait déjà l'impératif brutasse de l'assembleur. Il existait clairement le fonctionnel. Et il faudrait vérifier pour le déclaratif du Prolog – certes non mainstream. Toujours est-il que le procédural est loin d'être le seul paradigme majeur.

Le principe de fonctionnement de la POO est basé, comme dit plus haut, sur le fait que tout élément est objet et que chaque objet a un objet parent et éventuellement un objet enfant. Non, il n'y a pas forcément de parent, de même qu'il n'y a pas forcément d'enfant. C'est un détail.

L'objet, c'est d'abord un moyen de mettre en œuvre des services au travers d'abstractions, (via l'encapsulation), puis c'est une façon (dynamique?) de mettre en œuvre des points de variations (-> le polymorphisme d'inclusion, qui va s'appuyer sur l'héritage en effet)

La classe Personne que tu présentes est un très mauvais exemple de POO. Ce n'est qu'une agrégation de données, dans une syntaxe imposée par un langage à œillères OO. La différence que tu présentes avec du procédural ne se situe qu'au niveau du sucrage syntaxique de l'initialisation de l'agrégation. Elle ne touche pas les fondements de la POO. A la limite, on pourrait évoquer qu'un constructeur positionne l'invariant de la Personne, mais ce n'est pas l'objectif premier de l'OO. C'est un bonus important de beaucoup de langages OO, mais pas de tous je crains.

Si tu veux un exemple de différence entre la POO et le reste, c'est ceci qu'il faut regarder : http://fr.openclassrooms.com/forum/sujet/comment-le-c#message-87210210

J'insiste sur les setters : c'est l'antithèse de la POO : la prog orientée données. Les getters, ne provoquent pas des ruptures d'encapsulation aussi importantes quand les langages permettent un accès en read-only, mais ce n'est pas toujours le cas.

La vision de l'héritage est également trop technique à goût : orientée vers les fonctions mises à dispositions, et non vers la substituabilité qui est l'objectif majeur de l'héritage.

Concernant extends/implements, c'est de la bidouille technique Java qui passe à côté de la dualité de l'héritage qui est vraiment importante: substituabilité (cf LSP) VS import de code (sans substituabilité).

Bref, je dirai de reprendre les présentations. Si tu veux rentrer dans la technique, alors le tuto de conception devient un tuto de langage. Mais il y a déjà bien assez de choses à dire sur la conception OO, et de mythes à briser.

EDIT2: Tiens, j'avais manqué ça

Il existe même sur certains langages en OO (orienté objet) comme PHP, un destructeur qui sera appelé lors de la destruction volontaire (ou involontaire) de l'objet. Mais on utilise rarement cette méthode…

Les destructeurs sont juste la propriété du C++ qui fait toute la différence avec le C. Ce n'est certes pas une caractéristique fondamentale des langages OO (vu que peu en ont), mais c'est le moyen (déterministe et implicite) par lequel on finalise tout, sans exceptions. -> fichiers, mémoire, sockets, pots de peinture, … En Java, tu as le dispose-pattern (try+finally) (déterministe et explicite) et le try-with-ressources (?) depuis la v7.
Bref, les destructeurs sont au centre de ce que l'on appelle le C++ Moderne. C'est grâce à eux que l'on a des codes maintenables sans fuites ni rien. Donc, peut-être en PHP c'est le cas, mais en C++, on n'utilise certainement pas rarement les destructeurs. Bien au contraire on en use en permanence.
fin EDIT2

PS: Désolé si mon message peut paraitre "rude", il faut dire qu'il est tellement facile de s'arracher une jambe en C++ que l'on devient super tatillons sur la théorie qui l'on peut appliquer. ^^' Je sais que la tâche est rude. Bon courage.

EDIT: PPS: @Looping, ce que fait la notion d'interface, c'est qu'elle force aussi le respect du LSP. Et sans LSP il ne peut pas y avoir d'héritage multiple qui tienne la route.

Je continue ici, plutôt que d'éditer mon message.

On fait la différence entre propriétés et attributs en OO. L'attribut, est le détail invisible d'un objet qui permet de stocker son état. La propriété est une fenêtre vers une information que l'objet rend visible. On accepte pratiquement de violer (la loi de) Déméter dans le cas des propriétés, et donc de fournir des setters parfois. Mais pas nécessairement. De plus propriété ne veut pas dire attribut. Ex: l'âge d'une personne est une propriété, mais l'attribut sera très certainement la date de naissance. Et comme je le disais (mais non, je n'insiste pas! Si ? Vous croyez?) : transformer tous les attributs d'une classe en propriétés (getters + setters) est une erreur de design, et une faute de goût en violation avec les fondements de l'OO: offrir des services et autres abstractions.

Et non, l'objectif d'une méthode n'est pas de modifier un attribut. En revanche, une méthode va exploiter, et éventuellement altérer, l'état de l'objet sur lequel elle est appliquée pour faire rendre un service à l'objet. Bien sûr, l'état de l'objet est décrit/encodé par ses attributs propres ou hérités, directement ou indirectement, mais ceci est un détail.

Je vais faire court. Premièrement, je n'ai pas la forme question-réponse-dialogue entre l'auteur et le lecteur, style SdZ. Je ne trouve pas que cela rende la lecture plus agréable, mais par contre cela donne un aspect peu sérieux au tuto.

Et surtout, cela ne va pas dans le fond. On sent que le sujet n'est pas maîtrisé. Il y a beaucoup trop d'approximation, voire de choses fausses. L'organisation logique ne va pas non plus (parler de SOLID dès le début, comme si cela être trivial, pour revenir ensuite sur des bases de la POO, cela n'a pas de sens). Des remarques ont été faites, mais non pas été prise en compte. Le titre est "conception" alors que cela ne parle que de bases. Vision des objets orientées données et pas services. Voire une vision erronée de ce qu'apporte réellement la POO (pas simplement gagner quelques lignes de codes)

Cela n'est pas très grave d'écrire sur un sujet que l'on maîtrise pas, cela permet d'améliorer ses connaissances (et il y a suffisamment de relecteurs techniques pour signaler les problèmes). Par contre, cela demande un gros travail de recherche de références et de lecture. Le minimum est de faire apparaître les sources que vous avez utilisé en fin d'article (et s'il n'y en a pas, hum…)

Je surenchéris sur gbdivers pour dire que je trouve que votre présentation fait fouilli. Il y a des trucs à droite et à gauche sans lien logique apparent entre eux, et le tuto est résolument trop orienté mise en pratique : vous êtes censés parler de concepts, donc naviguer majoritairement dans le monde de l'abstrait ; pourtant, votre tuto manque lourdement de définitions précises et arrêtées (qu'est-ce qu'un objet, qu'est-ce que l'abstraction, etc.) et de vagues analogies avec le monde physique ne peuvent en tenir lieu. En outre, pour un cours théorique, il vous faut absolument bannir les formulations du type « dans la plupart des langages, on utilise ce concept via le mot-clé untel » : il serait beaucoup plus intéressant d'examiner comment l'un ou l'autre langage implémente les concepts généraux de la POO, les objets de JavaScript n'ayant pas grand chose à voir avec ceux de C++. Enfin, comme globalement tous les cours que j'ai lus jusqu'à présent sur la POO, vous ne parvenez pas à faire comprendre en quoi elle est utile en dehors de quelques cas restreints : en clair, pourquoi je devrais me faire chier à changer complètement de paradigme de programmation pour un système qui à première vue n'apporte que des contraintes supplémentaires ? Prenez peut-être exemple sur la programmation fonctionnelle : l'utilité du changement paradigmatique est beaucoup plus visible dans les textes qui en parlent.