Depuis que j'en entends parler, de ces fameuses classes, j'ai décidé de m'y mettre. Malheuresement, plus j'avance et moins je comprends le concept. Faisant un peu de PHP, je n'arrive pas à trouver ou placer des classes pour rendre le code plus propre. Les sites, d'ailleurs, donnent des exemples peu concret type "commande de pizza"
 
J'aimerais donc savoir dans quels cas mettre des classes et si cela rendait le code plus optimisé. J'ai aussi mis un petit sondage pour savoir qui, a part les dieux du php du forum, utilisaient ces classes qui me semblent pour l'instant inutiles (en réalité je me suis encore trompé de bouton )
 
Merci d'avance
 
WiiDS

 
Pour plus de renseignements, recherche dans google PHP 5 classes et tout ce que tu peux trouver sur l'orienté objet. Ca va carrément changer ta vision des choses...

 
Et sur google, c'est commande de pizza

Trouve de la doc sur les design patterns, c'est du concret par rapport à la conception objet.

Moi, ça dépend des jours et des langages
 
En Java j'utilise des classes parce que j'ai pas le choix, en Erlang j'utilise des modules et des fonctions parce que j'ai pas le choix, en Python et en JS j'utilise  à la fois des fonctions et des classes/objets, parce que j'ai le choix et que je prends donc ce qui semble le mieux rêgler mes problèmes (quand il faut lier des données à des comportements, avec plein de comportements internes planqués et plein d'état partout je fais des classes, sinon je fais des fonctions qui agissent sur des CDT simples)

Moi,  si le langage le permet,  mème de façon limitée (comme javascript),  c'est toujours des classes.  Ca oblige a bien définir, comprendre et isoler les concepts qu'on manipule dans son programme. Ca facilite le débugage aussi et parfois la réutilisation du code.
Maintenant,  c'est comme tout,  on peut aussi créer de la m... avec ça.

Y'a pas de classe en javascript mais uniquement des prototypes
Citation d'un expert:

 
Avec des classes tu as le design pattern MVC tout cuit dans le bec. Tu fais correspondre tes classes aux tables de ta base de données et ça devient super simple à gérer, du genre $object->insert().
Et si tu travailles un peu tu découvrira qu'il est possible de générer ta base de données à partir de tes classes PHP.
 
Si avec ça tu ne vois pas l'intéret des classes PHP, je ne peux rien faire de plus pour toi.    
 
 

Pour la BDD j'ai effectivement vu ca sur PunBB, qui utilise des $db->
 
Mon problème finalement c'est que je n'arrive pas a caser des classes, je veux dire trouver l'endroit ou en mettre une pour simplifier la tache Surtout qu'on peut finalement faire ca avec les fonctions

Le truc c'est de découper ton programme en objets qui vont collaborer. Chaque objet a des attributs (états internes) et des méthodes (capacités à agir sur le monde qui l'entoure).
 
Il faut commencer par écrire un objet maitre, qui gère tous les autres. Puis cet objet va faire appel à d'autres objets, etc...
 
Là où ça devient intéressant c'est quand tu commences à faire de l'héritage. Ton code devient magnifiquement beau, propre et parfois dynamique (ex : introspection). Il y a également des aspects te permettant de controler les accès qu'un objet fait sur les attributs d'un autre objet (getters/setters) : c'est l'encapsulation des données.
Si tu utilises un fichier par classe, alors ton application devient modulaire. chaque fichier possède une classe définissant un ensemble de fonctionnalités qui partagent des attributs.
Puis tu finis par ecrire de moins en moins de code et tu améliores la lisibilité de tes sources.
 
En résumé, écrire en objet, au début, est plus une question de vision qu'autre chose. Après, si tu veux passer au niveau supérieur, cela devient indispensable.

un exemple concret ? tiens en un (très simple en plus )
 
prenons comme exemple un page topic dans un forum :
on : titre, message, categorie, auteur, date_post, nb_reponses, nb_vues, etc.
 
dans un systeme traditionnel, pour afficher cette page, on fait :
1. requete sql sur le ID du topic.
2. faire le mysql_query, fetch_array etc. pour recuperer le tableau de données.
3. afficher ces données, mais là, probleme, les donnes qu'il nous faut se trouvent sur différentes tables, et y'a des count a faire, donc :
   3.1. recommencer 1. 2. et 3. mais sur le user(celui qui a posté le topic), pour chopper son nom, email etc.
   3.2. faires quelques count sur les nb_vues et nb_reponses etc.
4. afficher tout le tralala...
 
alors qu'avec les classes on peut un truc du genre :
1. include("le fichier de ma classe" )
2. instancier mon objet topic ($t = new Topic(son ID))
3. afficher la total :
titre : $t->getTitre()
auteur : $t->getAuteur()
nb_reponses : $t->getNbReponses()
etc.
 
tout le travail a été fait à l'intérieur de ta classe topic, il ne te reste plus qu'a utiliser ce qui est n'attends que d'etre appelé ; tes méthodes
 
ceci est un exemple assez simpliste, imagines un peu le projet de ouf super complexe avec 36000 tables a gérer et tout et tout...

Un truc que j'ai rencontré il y a pas longtemps: les moteurs de templates.

On commence avec une template textuelle, on va la parser pour pouvoir la traiter, donc on crée une fonction "parse" pour parser et une fonction "render" pour l'afficher. Jusque là tout va bien.

Le problème, c'est que dans cette template il y a des sous templates, des éléments de templates qui vont traiter des itérations, des propositions conditionnelles, ... et ces différentes sous-templates ont toutes des modes de rendu très différents (parce qu'il y a des logiques variables à appliquer), donc on se retrouve avec plein de cas particuliers bordéliques et de conditions dans notre fonction 'render' (on oublie la partie parsing).

Donc plutôt qu'avoir une structure template uniforme avec plein de bordel dedans, on va plutôt créer un objet Template de base, avec une méthode unique "render" (on peut en ajouter d'autres, mais c'est la principale). Et dans cette méthode, on a la logique applicative permettant d'afficher une template "racine" (principalement rendre toutes les sous-templates, et renvoyer le résultat).

Ensuite, pour chaque sous-template on peut créer une classe dérivée de Template: IfTemplate, ForTemplate, WhileTemplate, ... qui vont avoir strictement la même interface que Template, càd une unique méthode "render", mais elles auront leur logique applicative perso dans leur méthode "render". De plus, nos templates étant spécialisées elles peuvent stocker spécifiquement les éléments dont elles ont besoin, et potentiellement effectuer des optimisations à la compilation (à l'instantiation toussa): on regroupe les données et les comportements (méthode render) au sein d'entités independantes.

De cette manière, on peut tester une sous-template totalement en isolation (puisque son comportement à elle ne dépend pas des comportements des autres) et si une sous-template a un bug, la zone à surveiller/observer est limitée et contenue.

De plus, si on veut créer une sous-template (IncludeTemplate par exemple) on crée simplement un nouvel objet (et on modifie le parser, mais c'est un autre problème), les autres sous-templates n'ont pas à changer parce qu'elles se foutent éperdument des détails de l'implémentation de la nouvelle sous-template.