Discussion :

[maxx-out]

Bonjour,

Je développe depuis un demi-million d'années en PHP (3, 4, 5), ce qui m'a donné -certainement- pas mal de mauvaises habitudes. Voici ma manière de travailler, en quelques mots :
- un fichier de fonctions "génériques", réutilisables telles que. Par exemple des conversion de format de date, des tests de format de chaine, etc. Je me suis imposé strictement une rétrocompatibilité sur ce fichier
- un fichier de fonctions spécifiques au site concerné
- un fichier centralisant les "actions", c'est à dire ce qui doit être fait lorsque, par exemple, un formulaire est rempli. Bien entendu celui ci est spécifique également

Vous noterez dans tout cela, point de POO, mais une organisation à la mode "ma gueule"

Depuis quelques temps, on m'assène une vérité première qui dit (je résume) que tout ce qui l'es pas POO est tout pourri et tout vieux. Alors comme je ne veux pas mourir idiot, je m'y colle. Je n'ai pas de problème particulier de syntaxe, et je dirais que fonctionnellement j'obtiens ce que je veux. Pour autant, je suis face à un important problème qui me fait penser que soit je n'ai pas tout compris au concept, soit qu'on m'aurait menti sur le tout pourri de mes vieilles habitudes.

Voici un exemple concret. Je veux obtenir un bête tableau qui liste les membres de mon site, la date de leur dernière visite, et le nombre de messages postés dans le forum. Je prends cet exemple exprès, car les 3 données sont dans 3 tables différentes.

Méthode avant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$q=mysql_query("Ma requete qui va bien avec jointure qui vont bien pour récupérer en une seule fois toutes les infos de tous les membres");
while ($r=mysql_fetch_object($q)) {
// ma ligne de tableau, avec pseudo, date dernière visite, nombre de messages forum
}

Méthode POO :
D'une part ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Membre {
  function getInfos($idmembre) {
    // requete qui me récupère les infos de base pour le membre passé en argument
  }
function getPseudo() {
    // ici pas de requête, je ne fais que récupérer le pseudo obtenu par getInfos
  }
  function getDerniereVisite() {
    // requete qui me récupère la date de dernière visite
  }
  function getNbMessages() {
    // requete qui me récupère le nombre de messages postés
  }
}

Et d'autre part ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
$q=mysql_query("Requete pour récupérer les id des membres qui m'intéressent");
while ($r=mysql_fetch_object($q)) {
    $m=new Membre;
    $m->getInfos($r->id);
    echo $m->getPseudo();
    echo $m->getDerniereVisite();
    echo $m->getNbMessages();
}

Bon, c'est un code schématique, bien entendu, pas le réel. Juste pour l'exemple.

En procédant de cette manière, il arrive ce qui devait arriver : c'est lent, très lent... Et en fait c'est un peu logique : plutôt qu'une requête complexe, je fais faire au serveur une requête simple puis 3 requêtes simples par membre.

Bien sûr, dans de nombreux cas je n'affiche que les infos d'un seul membre, au pire deux, donc ce n'est pas super impactant. Mais il suffit que je tombe dans des cas du type :
- liste des membres avec telle ou telle info
- thread d'un forum, avec pour chaque post affichage de quelques infos sur le membre
Pour que cela tourne au vinaigre.

Donc voici mon problème : où merdé-je ? J'ai bien imaginé faire une autre classe qui possèderait des méthodes spécifiques pour récupérer les données dans tous les cas tordus, mais à la fin, je n'ai vraiment pas le sentiment de faire quelque chose ni de très propre, ni de très maintenable, en tout cas pas davantage que ma méthode de papy.

Merci à à toutes celles et tous ceux qui pourront éclairer ma lanterne sourde.

[metagoto]

Je ne vois pas ce qui t'empêcherait de prendre ta première méthode, celle avec la query aux multiples jointures, et de fetcher chaque row dans un objet Membre. Aussi, avec PDO, on peut directement fetcher dans un type (class) défini.

D'un point de vue général, ce n'est pas parce qu'une appli est "POO" que les requêtes seront moins optimisées. Il faut juste agencer les trucs correctement.

Donc voici mon problème : où merdé-je ? J'ai bien imaginé faire une autre classe qui posséderait des méthodes spécifiques pour récupérer les données dans tous les cas tordus, mais à la fin, je n'ai vraiment pas le sentiment de faire quelque chose ni de très propre, ni de très maintenable, en tout cas pas davantage que ma méthode de papy.

Mettre des classes partout, ce n'est pas vraiment faire de la POO. En revanche, tirer partie du polymorphisme, du LSP, de l'encapsulation, du type hinting, des design patterns, c'est déjà mieux faire de la POO. Plus les projets sont importants, et plus ça aide (on pourrait rajouter l'autoloading, les exceptions, la reflexion, les méthodes magiques...).

On a la chance d'avoir un php qui soit à la fois procédural et orienté objet. Il faut je pense utiliser les deux paradigmes à bon escient et ne pas rejeter l'un ou l'autre par idéologie. Si tu es tout à fait à l'aise avec ta façon de faire, pourquoi ne pas continuer ainsi ? Par contre c'est vrai que d'un point de vue théorique, c'est quand même important de maîtriser les bases de la POO, ne serait-ce que pour comprendre des codes tiers.

Pour finir, voici un célèbre post de Rasmus Lerdorf qui présente une approche pragmatique et procédurale face aux architectures MVC objets qui se répendent comme une traînée de poudre
The no-framework PHP MVC framework

[maxx-out]

Merci pour ta réponse metagoto.

En fait je n'ai pas l'intention de passer à l'extrême inverse, surtout que mon approche procédurale a fait ses preuves, et que j'ai de nombreux sites qui s'appuient sur cette logique. En fait je souhaite juste progresser, et aller vers de la POO là où c'est pragmatique. Je ne peux nier que certaines portions de mon code ont de quoi coller des migraines pour toute personne qui passerait derrière moi...

Je réfléchis à créer une classe qui traiterait les alimentations "de masse" d'objets Membres, avec des méthodes spécifiques à chaque requête complexe, et des méthodes communes pour l'alimentation de l'objet en fonction du resultat de la requête.