Forum d'entraide PHPFrance

Bonjour à tous,
Cette nuit dans mes rêves je réfléchissais à PHP avec de la POO, le modèle MVC etc..
Bref là n'est pas le problème mais une question me turlupine. En effet je suis quand même un vieux de la vieille en PHP et j'ai du mal à évoluer vers la POO avec ce langage.

Ma première question est la suivante:
Comment réalise t'on des classes avec PHP ? (je ne parle pas de la syntaxe mais des méthodes et des attributs que l'on y gère)
En effet comment savoir quelles attributs mettre etc...

Par exemple j'ai une base de données qui gère des clients avec une table CLIENT(id_cli,nom_cli,..)
Est ce que je dois me faire un graphique UML de mon application PHP ? Sachant que UML serait lui même aligné sur mon MCD d'origine...

OUi j'avoue je pose des questions bizarre mais je comprend pas trop pourtant j'aimerais bien passer à la POO en PHP et avec le modèle MVC qui plus est.

Voilà pour mes questions...
Car en fait je n'ai jamais vu de tutorial expliquant comment créer logiquement ces classes PHP avec des modèles UML... J'ai peut être mal cherché ?

Bonne fin de journée à vous.

Thibaud

Hey ,

Si tu es l'akrogames qui s'appelle Thibaud à qui je pense, tu n'es pas plus vieux que moi en PHP .

Je crois que tu n'as pas compris l'importance de la programmation orientée objet et son but surtout. C'est difficile à résumer en 5 lignes, mais grossièrement une classe augmente la modularité de ton application car on effectue une atomisation du code. On entend par là que l'on découpe le code en petites opérations simples (quasi logique si je peux me permettre). Une classe va ensuite travailler sur un sujet précis, en rassemblant justement ces briques et en les proposant à l'utilisation. On ne rassemble pas n'importe quelle brique, il faut qu'elle travaille dans le même sens.

Ensuite pour la question des attributs, il faut voir ta classe comme une boîte que l'on interroge. On y dépose des données, et quand on l'interroge, elle rend les données sous la forme adéquate, traitées, bidouillées, triturées etc. Les données que l'on injecte dans la boîte navigue de méthode en méthode, mais certaines données sont communes à plusieurs méthodes. Il faut donc les stocker temporairement : dans les attributs.
On peut également stocker des objets dans des attributs, c'est ce qu'on appelle l'association. Je ne rentre pas dans les détails, mais on peut faire beaucoup de chose et mettre en place des mécanismes très intéressant.

Après il faut comprendre ce qu'il se passe en mémoire, et je n'en ferai pas le détail. Mais en gros : tu as une classe ; quand tu instancies ta classe en objet, les méthodes appartiennent à la classe et les attributs à l'objet. Exception fait pour les éléments statiques (attributs ou méthodes) qui appartiennent à la classe et non à l'objet. Donc un objet est au final assez léger, car il fait — grossièrement — le poids de ces attributs (plus quelques octets pour différentes autres informations).

L'avantage de la POO c'est qu'elle permet une meilleure organisation du code et te force à avoir une hiérarchisation de ton code (à travers des mécanismes bien connus comme l'héritage, l'association …). Je pense que tu trouveras suffisamment d'exemple dans la littérature.

As-tu partiellement compris ce que je veux dire ?

Merci mon petit Hywann de tes explications. Je suis bien l'AkrogAmes à qui tu pense.

Clairement j'ai saisie la théorie tu comprend mais pas la pratiques. Je ne vois pas comment dans ma petite tête on peut utiliser des bases de donénes avec du PHP en POO....

Je vois bien de nombreux exemples sur des sites mais rien de concret. J'ai lu un peu ton framework hywann pour regarder comment tu faisais mais j'avoue que des chosesme passait au dessus de la tête. Bon je vais paufiner tous cela. Merci quand même

Commence par des choses plus simple. Comme un paquetage pour les mails, ou pour les caches. C'est utile et très simple. Ça te fait aborder aussi certain problème intéressant (pas mal de notion seraient à aborder).

Si tu t'attaques à de l'ORM, sache que c'est très dur (et je sais de quoi je parle) à bâtir.
Si tu t'attaques à une base de données objets, c'est pas simple mais ça va. C'est surtout extrêmement puissant et permet plus de chose qu'une base de données relationnelle. À bâtir, tu laisses tomber, c'est de la haute voltige .
Si tu t'attaques à PDO, bah lis le manuel. L'utilisation n'est pas sorcier .

Mais qu'est-ce que tu veux faire exactement ?

Ah voilà, pour bâtir une application avec une BDD relationnel il y a des méthodes ORM comme PDO j'ai bien tous saisi?

Je vais commencer par des gestions de mails en Objet.

Voilà

Merci Hywann pour ces précisions.

Alors tu fais des confusions là.

Un ORM (Object Relationnal Mapping) permet d'avoir un comportement objet pour une base de données relationnelle. C'est un fake si tu veux. Un des buts aussi de l'ORM est de construire automatiquement des requêtes, de les envoyer dans ton système de gestion de base de données, et de fournir les résultats sous une forme acceptable.

PDO (PHP Data Object) — quant à lui — est une couche d'abstraction vers des bases (MySQL, Oracle, SQLite, …). Cette couche d'abstraction est écrite en objet (pour la partie PHP). PDO envoie les requêtes dans la base, et te permet de récupérer et de traiter les résultats de manière élégantes, mais ce n'est pas lui qui écrit les requêtes, attention.

Désolé de "m'incruster" dans la discussion pour la détourner ( je ne pense pas que ma question vaille un nouveau topic et ne serai pas ou poster ) mais je ne suis pas un habitué de PDO et voudrai savoir si en pensant que cela se rapproche du principe d'hibernate pour le java je suis sur la bonne voie?

Hibernate fait beaucoup de chose. Je connais Hibernate pour son ORM mais je ne sais pas s'il se touche aussi à l'abstraction d'accès au base de données. Un coup d'œil dans notre encyclopédie libre préférée serait le bienvenu non ? Donc apparemment, Hibernate s'occupe de la persistance des données, ce que ne fait pas PDO car PDO travaillent sur du relationnelle et pas de l'objet.

Attention aux confusions entre ORM et PDO.

Si tu es javaîste, PDO correspond plus ou moins à un driver JDBC.

Hibernate est bien plus de cela. Au final, PDO fait beaucoup de bruit pour pas grand chose (j'entends par là, pour quelqu'un qui vient du monde Java)...

Bonsoir,

Malgré le résolu je viens mettre mon grain de sel.

ORM, PDO, UML, MVC autant d'acronymes brandit à tord et à travers ...
Désolé de dire cela mais je trouves amusant tout ces concept novateur de trois lettres censé révolutionner les moeurs des programmeurs .

L'objet c'est tres simple à condition de commencer par marcher avant d'essayer de courir

dans le cas présent celui de tes clients, un objet te permettrait par exemple de manipuler un client au sein d'un meme entité, l'objet.
je passe sur la syntaxe pour rester sur l'idée. l'idéal de l'objet c'est de manipuler des données non plus par des "forces" exterieures comme on le fait en procedural mais par des "forces" internes, l'objet client sait se charger de lui meme dans la base.
En l'état cela nous donnerais une classe très longue contenant les requetes sql pour interoger la BDD, l'affichage etc
Mais dans l'idée on a deja un gain par rapport a ce que l'on avait avant dans l'arborescence de notre site puisque l'on a centralisé la quasi totalité de ce qui touche au client au meme endroit.

Admettons maintenant qu'en plus de ton objet client tu ai besoin d'un objet fournisseur. On se retrouve avec une nouvelle classe contenant à nouveau des appel à la BDD...
Dans ce cas pourquoi ne pas faire une class qui va gerer les appel à la base pour les centaliser au meme endroit?

c'est à mon sens une première approche de l'objet qui permet déja de se familiariser avec le concept objet sans se perdre dans les méandres de la POO. A l'usage, des questions appeleront ou souleveront de nouveau point qui seront des levier pour passer au stade suivant.

J'en profites au passage pour faire une petite remarque au personnes ayant repondues, pensez à vous mettre à la portée de celui qui posent la questions avant de partir trop loin pour qu'il vous suive ....

Hey ,

Saevas a (très) raison quand il dit que l'objet est facile. Si on s'y prend méthodiquement, on ne réfléchit que sur des atomes du programme, c'est facile. Et à la fin, on assemble tout, rien de sorcier. Si c'est clair dans notre tête et que l'on a fait ne serait-ce qu'une brève analyse du problème, on ne devrait pas en rencontrer.

La chose un peu compliqué dans l'approche objet est de savoir à qui appartient quoi et qu'est-ce qu'on doit en faire. Après, il existe d'autres mécanismes plus compliqués, mais ça s'apprend avec le temps.

Et comme pour toute phase d'apprentissage, on commence par faire des choses inutiles, mais pas si inutile que ça …

Si tu es javaîste, PDO correspond plus ou moins à un driver JDBC.

Hibernate est bien plus de cela. Au final, PDO fait beaucoup de bruit pour pas grand chose (j'entends par là, pour quelqu'un qui vient du monde Java)...

merci c'est exactement ce que je voulait savoir. Ne m'etant intéressé que superficiellement à PDO je surestimait en effet les possibiltées...

En fait j'ai récement utilisé Hibernate pour rendre plus élégant et plus "objet" mon accès à une BDD (utilisant précédement JDBC) et m'imaginait naîvement pouvoir porter le concept dans le carde d'un développement PHP5 mais visiblement ce ne sera pas possible...