,Tu devrais vraiment te pencher sur la gestion de fichier (file system) sous Unix. C'est une petite merveille de simplicité (inventé presque 10/15ans avant le DOS soit dit en passant …).
Je t'explique rapidement en faisant la parallèle avec l'objet.
Tout est fichier : dossier, lien symbolique, lien dur, fichier, volume, périphérique, etc. Donc, on aurait un objet fichier. Chaque fichier a un identifiant, c'est ce qu'on appelle un inode (identifiant de nœud). Chaque inode est unique, normal. À chaque inode est associé une donnée (souvent une suite de bit, mais pour notre objet, on va utiliser des attributs par exemple, pour simplifier). Cette donnée comprendre plusieurs choses : le type du fichier (dossier, lien, volume, fichier, etc.), ses droits, son propriétaire, son poids, etc. Un disque dur, c'est alors un tableau associative inode → données ; tu vois facilement le parallèle avec l'objet : un disque dur est un objet HardDisk qui contient une collection d'objet File, tout bêtement.
Oui mais l'arborescence alors ? On a dit que chaque fichier avait un type particulier. Dans le cas d'un fichier normal (fichier texte par exemple), on aura le type du fichier à null. Dans ce cas, son contenu sera traité comme du texte. Maintenant, dans le cas d'un dossier : son type sera d, et donc, son contenu ne sera pas interpréter comme du texte, mais autrement. Son contenu c'est tout simplement une liste d'inode qui représente le contenu du dossier. Tu vois donc comment créer une arborescence ? Tu as ton élément racine d'inode fixe, imposé, invariable, et connu (une constante par exemple) qui est un dossier, et qui contient tous les éléments de départ. Après, il est facile de faire une arborescence.
En objet c'est pareil donc. Chaque objet a un « profil ». Le profil peut être décrit via les attributs de l'objet, à toi de débrouiller comme tu veux.
Une chose intéressante toutefois : le type géré par héritage. Si on ne gère pas le type par héritage (i.e. on a une seule classe pour tous les fichiers), il sera géré via un attribut, et une méthode isFile, isDirectory, isLink, etc. Mais si on le gère avec l'héritage, c'est à dire que la classe Directory étend File, alors c'est plus intéressant. Imagine ta classe HardDisk qui contient une collection de fichier, elle peut contenir des objets typés comme File ou typés comme Directory. Le test est immédiat : instanceof. C'est plus rapide, plus souple, et plus léger. Si tu as un seul objet File pour tous les fichiers, il va faire 2000 lignes, et bonjour pour le modifier (exemple tout bête : ajouter un type) … Alors que si ton objet File permet de gérer les propriétés communes à tous les fichiers (inode, poids, nom, etc.), et que tu as un objet Directory qui étend File, avec la surchage, la redéfinition, et des choses du genre, tu peux vraiment te faciliter la vie, et utiliser des objets appropriés. Comme tu l'as dit toi-même, la programmation orientée objet va du plus abstrait au plus concret. C'est ce qu'on fait ici.
Après, quant à l'utilité de faire un tel système pour PHP, euh … bonne chance, mais je n'en vois pas. C'est un excellent exercice pour comprendre la POO. On utilise des mécanismes très intéressants, et on peut pousser assez loin le raisonnement, pour ça bravo. Mais une implémentation concrète, en environnement de production, c'est assez inutile
.@Nagol : Sékil n'a jamais dit que programmer en procédural était crade … La POO a des avantages et des inconvénients, mais tout est question de contexte, d'environnement et de langage. On ne fait pas de l'objet en LISP, on fait du lambda-calcul. On ne fait pas du procédural en Java, on fait de l'objet. En PHP, c'est très compliqué. Le langage permet de faire du fonctionnel, du procédural, et de l'objet. Les applications répondent à une demande précise et très varié. À nous d'utiliser le style adéquate qui répond le plus aux exigences de l'application.
Il n'y a pas de guerre entre procédural et objet, c'est du vent, inventé sur IRC pour alimenter la longue liste des trolls. Tout ça parce que Java et C n'arrivent pas à cohabiter (et si je dis que le noyau de Java est écrit en C, on va me sauter dessus
?). Ce sont des styles très différents et qui n'ont presque rien en commun. Il y a des applications très complexes qui seraient quasiment humainement impossible à réaliser en procédural, et d'autres applications qui sont un réel casse-tête à réaliser en objet alors qu'elles seraient extrêmement simples en procédural. Ce sont deux mondes très différents qui ne méritent même pas la comparaison.L'idée que la plupart des gens ont sur le procédural, c'est un peu de PHP 3 ou PHP 4. C'est du procédural de little-player. Prolog est du procédural (mélangé à du lambda-calcul, et tout le toutime). Je vous mets au défis de faire de l'intelligence artificielle en objet. Le langage ne s'y prête pas une seconde.
Dire que l'objet ralentit les applications est une aberration. Une application correctement conçue en objet n'est pas tellement plus lente que si elle avait été conçue en procédural. Néanmoins, la maintenance va être nettement plus aisé en objet. C'est comme ça, c'est tout. Si l'objet a été inventé et est de plus en plus répandu, c'est qu'il y a une raison. Le procédural était partout alors qu'il ne devait pas être partout. À chaque besoin son style de programmation, et les styles naissent en fonction des besoins et de l'expérience.
On voit ce genre de réaction comme si le procédural allait mourir à cause de l'objet. Point de crainte amis, le procédural a encore une belle vie devant lui (et ça rime).
Je pourrai encore expliquer mon point de vue, mais ce serait autour d'une petite table, et un peu plus tôt. Moi, je vais me coucher
.
