bonjour,
 
J’aurais une question concernant php5 son modèle objet et ses performances.
 
Je suis adepte du développement objet depuis pas mal de temps surtout en java, qui ne pose aucun problème de performance avec la gestion des collections d’objets, chose que je fais régulièrement.  
 
Par contre php5 bien que gérant l’objet est sujet à pas mal de lourdeurs (d’après certains de mes collègues). Résultat ils développent en php 5 mais avec si peu d’objet que c’est grosso modo  encore en procédurale, pas terrible selon moi.
 
J’aurais donc voulu avoir votre avis sur les performances réelles de php5 POO.  
 
Voici un exemple, je souhaite par l’intermédiaire d’un moteur de recherche afficher une liste de voyages (objet voyage) ; cet objet est assez gros, disons une cinquantaine de propriétés. Disons que le résultat me retourne 30 voyages. En java pas de soucis, j’aurais fait un jolie tableau de collection d’objet voyage contenant mes 30 objets et basta.  
 
Avec php, on me conseille de faire plutôt que 30 instanciations (30 pointeurs), car ce serait trop lourd à gérer, de marcher par des tableaux associatifs pour afficher les résultats. Donc plus de gestion d’objets et duplication de code inutile (selon moi), pour gérer les tableau associatifs. Sans parler des problèmes de maintenance dans le futur.
En fait j’ai l’impression que certains utilise le modèle objet de php uniquement pour se servir des classes comme conteneur fourre tout, sans appliquer les principes de développement objet.
 
Qu’en pensez vous ?  
 
Il y aurait aussi la solution d’instancier des sortes d’objets light (avec moins de propriétés) pour les collections d’objets. Est-ce judicieux ?
 
Il faut ajouter également que chaque objet "voyage" contient plusieurs objet "hébergement" et que chaque objet hébergement contient plusieurs objet "tarifs".
 
Merci de vos réponses.

Un tableau de 30 objets, avec chacun 50 propriétés, à mon avis, ça va pas ruiner les perfs
 
Commencer à vouloir optimiser un programme même pas développé, c'est se faire chier inutilement et prématuré puisqu'en fin de compte, tu sais pas si les perfs seront pourries. Par ailleurs, en cas de pb, t'auras des moyens pour les améliorer les perfs (APC, résultats ou pages en cache...). Et pour rappel, c'est bien souvent les accès à la BD qui nuisent le plus aux perfs (et dans ce cas, là encore, y'a des solutions : analyse des requêtes pour optimiser les index, tuning des cahces/buffers de mysql...).
 
Conclusion : code proprement ton appli, après, si t'as des pbs, on en reparlera.
 
Et pour info, regardes Magento (outil de e-commerce en GPL), il est en objet et c'est un soft assez conséquent en MVC (Znd Framework). Ils ont eu certes des pbs de perfs dans les premières versions, mais dus principalement à la structure de la BD et un peu au système de templates.

Si tu utilises des foreach sans référence ( foreach($a as $v) {...} ) au lieu de foreach avec référence ( foreach($a as &$v) {...} unset($v); ), ton script peut consommer de la RAM pour rien, ce qui est deadly si le script manipule de mégas tableaux ou dure trop longtemps (style démon, while(1)).
 
Les auto getters et setters bouffent du temps, c'est à éviter.
 
Les auto loaders bouffent également du temps, mais si la définition de la classe est disponible (require_once 'blabla.php'; en haut de fichier), no soucy.
 
Comme rufo, je vois pas où est le problème côté perf.
 
 
Après pour avoir essayé personnellement ce genre de pattern, c'est au niveau logique la bancalité s'installe. Une requête croise 99,99% du temps plusieurs tables, il est donc structurellement impossible de sortir un objet métier correspondant à ton agrégat, d'où l'utilisation de structures plus simples et plus souples comme des tableaux.  
 
Où alors tu fais comme facebook (je recommande pas !), tu dénormalises ta table en créant une table / une vue d'agrégat et comme ça plus de joins et tu pousses les résultats dans ton objet qui mappe parfaitement ta table/vue.

Pour la BD, si besoin de perfs, il peut regarder du côté des bases NoSQL