Salut je pratique le php objet de puis quelques mois et j'en suis pleinement satisfait, cela m'a permis de réduire mon code de façon spectaculaire et de grandement simplifier sa maintenance.
 
Cependant, je trouve que depuis quelques temps mes pages sont plus longues à se charger. Je pense que cela vient de mes objets.  
 
Donc voilà ma question, la gestion des gros objets en php allourdi t-il les pages de façon notable, par rapport à des requête SQL direct ?
 
Par gros objets, j'entends parfois jusqu'à 100 variables membres et beaucoup de methodes. Certaines de mes définitions de class font dans les 2000 lignes.
 
Merci de vos réponses

 
comment tu arrive à des classes pareil  
 

En fait j'intégre dans mes classes des variables de gestion de langue (1 variable = 1 bloc de texte). Sans ces variables mes variables membres c'est un trucs genre 30 ou 40 maxi.

Moi ce que j'arrive pas à comprendre c'est le rapport entre tes objets et des requetes SQL ...
 
edit:

Euhh mais même 40 c'est énooorme ... Tu aurais un exemple d'objet avec 40 propriétés?
 
J'ai comme l'impression que c'est largement optimisable ton truc!

Ce que je veux dire par là c'est que tu peux :
 
Soit ne pas utiliser d'objet et faire une requête SQL directement en procedural  
 
Soit créer un objet appelant une méthode dans laquelle tu exécutes ta requête SQL.
 
Il me semble que le passage par l'objet est plus lourd, mais est-ce notable ?

Ben quand tu veux créer un class client et que ton client à entre 30 et 40 propriétés, comment fais-tu ?

Tu ne charge en mémoire que les propriété dont tu as besoin pour afficher la page. Si tu as besoin de 40 propriété par page l internaute risque de s y perdre: coupe tes pages ou ajoute des popups pour les photos/fiches techniques etc.. ça peut se faire avec des objets à condition de déclarer en début de page les propriétés qu il faut aller chercher dans la BDD. Si t organise tes bases et tes objets de façon à ce que le nom des propriétés soient les mêmes c est facile de créer des requêtes à la volée. Pour les fonctions de 2000 lignes idem: tu n a certainement pas besoin de toutes les fonctions sur toutes les pages, en organisant tes objets tu devrais arriver à ne charger que les fonctions dont tu a besoin par page, par exemple en créant plus d objets plus petits.
Pour les traductions, si tu garde en mémoire toutes les traductions de tous les messages, c est vraiment inutile: tu peut garder les traductions dans une BDD ou des fichiers et extraire uniquement celles dont tu as besoin pour une page donnée.
 
Si tu garde ton code obèse, le serveur charge en mémoire plein d informations qui ne seront pas affichées donc inutiles.

En fait je pensait que créer un objet et tout rapatrier dedans me permettrait de me connecter à la BBD 1 fois au début puis ensuite limiter les échanges entre mes pages php et ma BDD et uliliser les données de mon objet.
 
Ce n'est apparemment pas une bonne formule selon toi ?
 
Il faut aussi préciser que mes objets comprennent des fonctions d'affichages de tableaux et de présentations comme des listings. Cela explique la grosseurs des classes.
 
Est ce que je devrais sortir ces focntions de mises en forme des mes classes et ne pas les gérer en objet ?
 
Petite precision aussi, je n'ai jamais mentionné de FONCTION de 2000 lignes, mais des CLASSES de 2000 lignes. En fait il s'agit d'une fonction d'affichage dans ma classes qui est assez importante car la mise en forme y est importante.
 

> Ce n'est apparemment pas une bonne formule selon toi ?
 
Pas si tu charge des données inutiles (non affichées). De plus, l internaute est un humain qui ne retient qu ne moyenne 7 choses à la fois, si tu as 40 propriétés affichées par page il va être perdu dans le flot d informations.
 
> Est ce que je devrais sortir ces focntions de mises en forme des mes classes et ne pas les gérer en objet ?
 
Ce que tu peut faire c est des classes à part pour l affichage, pour ne charger en mémoire que les fonctions d affichage désiré. Tu peut aussi jongler avec PHP pour lui faire charger uniquement les fonctions necessaire dans les classes (je suis pas sûr comment ça marche, mais en te penchant sur la doc tu devrait trouver un moyen).
 
Si tu coupes tes pages, tes fonctions d affichage peuvent  elles aussi être coupées.
 

C est plus un problème de conception qu un problème objetPHP.
Essaye en priorité de voir si tu peut faire des sous-objets dans ta classe client, en organisant les propriétés selon leut utilisation commune.
 

jamesbond2 > Personellement, pour mon site, j'ai fait un systéme de template basé sur les idées suivante :

• on peut vouloir une même page affiché dans des formats trés différents (pdf et html par exemple) ou avec une tête différente (fichier de modéle html différent) => si chaque objet gérait son propre affichage, il faudrait tous les modifier dés qu'on veut rajouter un format ou une nouvelle tronche (pas jouable)
• on peut vouloir stocker une copie de la page dans un format tout en l'envoyant au navigateur dans un autre format (par exemple : pdf sur le disque et html dans le navigateur) => plustôt que de recalculer toutes les données, j'ai séparé la partie affichage de la partie "organisation hiérarchique des données"

En bref, j'ai séparé le traitement, le stockage des données (j'ai toute une série d'objet en fonction du type de contenu : simple texte, lien, table, formulaire ...) et l'affichage (un template pour chaque format : pdf, html ...).
 
Tout ça pour dire que si t'as des classes de 2000 lignes dont 1500 consacré à la mise en forme du résultat, alors c'est que tu n'as pas prévus une telle organisation. Au début, j'avais fait un peu comme toi (de l'html un peu partout dans du php) mais c'était pas jouable à terme et entre avoir un systéme de template bien conçu et de l'html partout, tu peux gagner facilement la moitié de la taille des fichiers tout en étant énormément plus souple au niveau des changement de l'affichage.

Peut être cela pourra t aider:
http://www.php.net/manual/en/langu [...] toload.php

[quotemsg=1324093,9,386759]De plus, l internaute est un humain qui ne retient qu ne moyenne 7 choses à la fois[quotemsg]Ca, c'est valable uniquement pour la mémoire court terme. La preuve, t'utilises t'as utilisé beaucoup plus que de 7 choses pour écrire ton message.
Ensuite, qu'il ai 40 propriété dans sa classe, je vois pas trop en quoi s'est génant s'il en a vraiment besoin pour un traitement donnée. En plus qu'il y en ai 40 ne veut pas dire que l'internaute ou le développeur aura accés aux 40. Peut être qu'ils n'en véront pas plus de 10 si le reste est en "private" ou en "protected".
 
Par contre, là où je suis d'accord, c'est qu'il est inutile de charger 2000 lignes de codes si c'est pour n'en utiliser que 200.

Avec PHP5 tu peut définir des classes abstraites.
Ton objet de base ne possède pas de fonctions d affichage, tu écrit ensuite plusieurs classes avec des fonctions affichages qui dérivent de la classe de base pour afficher suivant diverses présentations.

je suis pas vraiment d'accord avec cette partie là de ton message : le langage objet est sensé être plus compréhensible par l'humain car sensé être plus proche de sa façon de penser : un objet par concept dans le système. Définir une classe en fonction des besoins des pages, je ne trouve pas que ça soit une bonne chose. Un objet doit contenir toutes les méthodes nécessaires aux actions sur le concept qu'il représente. Si on commence à partitionner les objets en fonction de telle ou telle page, on a pas fini, et niveau maintenance du code, c'est plus compliqué. (et le monsieur le dit lui-même, il ne parle pas de fonctions de 2000 lignes, mais de classes de 2000 lignes. Ce qui ne me choque pas.)
 
>Omega2 : +1. C'est pourquoi personnellement pour chaque objet, je sors dans une autre classe les méthodes d'affichage.
Par contre Omega2, tu as des objets gêrant l'affichage de chaque élément d'une page ? (par exemple une méthode pour afficher un lien hypertexte, une méthode pour afficher un tableau, etc ... ?).
Perso, j'ai plutôt des méthodes gêrant l'affichage de mes objets à proprement parlé (par exemple, une méthode pour afficher le menu des utilisateurs non-connectés au site, une méthode pour afficher le menu des utilisateurs connectés au site). Ainsi le code html est également dissocié du code PHP.  
Tu en penses quoi ?

Djebel1> il a certainement besoin d héritage de classe, un concept tout à fait objet. Avec l autoload ça devrait être efficace.
 
 
 
 
 
 
 

oui mais je ne pense pas que le fait qu'une classe fasse 2000 lignes soient un élément assurant qu'il doit utiliser les héritages, ou que ses classes soient mal pensées. J'ai actuellement un projet avec deux classes de + de 2000 lignes, et les méthodes leur sont totalement spécifiques et indispensables

> Par contre, là où je suis d'accord, c'est qu'il est inutile de charger 2000 lignes de codes si c'est pour n'en utiliser que 200.
 
Ça vaut aussi pour les données chargées à partir de la BDD.

Bah oui, mais on revient au même : si tu as un objet avec 20 méthodes, et 4 pages utilisant chacune 5 méthodes de l'objet, tu ne vas pas découpé l'objet en 4 juste pour que les autres méthodes ne soient pas chargées inutilement.
 
Multiplier les objets dans tous les sens, c'est surement mieux "performance wise", mais "compréhension du code wise", c'est chiant.
 
Et n'oublions pas que, OUI, l'objet ralentie les perf, au bénéfice d'un code compréhensible et maintenable. A voir ce que tu dois privilégier dans ton projet (me semble par exemple que les noyaux linux sont codés en C, sans objet non ?)

Euuuuuuh ... je pense plutot qu'un truc mal conçu (en objet ou pas ralentit) les perfs mais qu'on arrive plus facilement à des grosses bouses codées n'importe comment en utilisant les objets.

Djebel1 > J'en pense que c'est une autre façon de faire. Peut être que ton systéme est meilleur que le miens ou moins bon, le principal c'est que ca soit évolutif, facile à débugguer et que ca rame pas trop.
 
Moi, j'ai préféré avoir un systéme capable d'autoévoluer le plus possible en fonction des besoins pour ne plus me retrouver coincé comme avant. Avec ce que j'ai fait, je peux créer un nouveau module constitué d'une ou plusieurs classes et ne pas avoir besoin de modifier le reste pour l'utiliser.
 
Sinon, comme je n'ai pas ton code sous les yeux, j'ai l'impression que tu vas te retrouver avec pleins de méthodes dont une partie auront un code vraiment trés ressemblant. (ok, moi, c'est pleins de classes quasi identique et aussi quelques classes parfaitement identiques à leur signification prés. )

Djebel1> as tu besoin de toutes les méthodes à la fois dans toutes les pages? si oui, alors tu ne peut pas réduire le code chargé (il est entièrement necessaire à l affichage d une page), si non tu peut te pencher sur l héritage pour alléger le traitement.
 
Quand à découper les pages, celà revient à se poser la question: est-ce que l internaute a besoin de toutes les informations à la fois?
 
Lorsque le modèle objet sous-jacent reste le reflet de l interface graphique, les temps de traitement sont fonction de la taille des pages. Sinon, pour afficher <<Bonjour cher(e) Internaute>> tu te trimballe 50Ko de données et 30Ko de code.
À mon avis 1 page = 1 classe est un bon principe pour éviter les objets obèses.
 
En plus, avec PHP, tu peut rendre tes classes de base modulables et ainsi alléger l organisation du code. Pourquoi s en passer?
 

Franchement je voudrais bien voir ton diagramme objet parce que j'en suis sur que en faite tes classes sont des sacs a fonctions.
J'entend sac à fonctions c'est des classes qui englobe des fonctions et exploiter la syntaxe des classes car dans un certain c'est utiles pour ceux qui ne connaissent pas reellement le devellopement en objet.
c'étais mes debut dans le php
 

C'est aussi un bon principe pour faire n'importe quoi sur son modèle.
On va prendre l'exemple d'un cours définit par une salle, un professeur et des eleves.
Petit modèle objet vite fait: en plus de la classe Cours, 4 classes ( Salle, Personne, Professeur ( héritant de Personne), Eleve ( héritant de Personne)).
Si tu veux dire que pour la page "afficher un cours", tu crées juste une classe Cours, désolé mais ça suXXe.
Au vu de ce que tu disais avant je pense pas que ça soit ce que tu voulais dire, mais c'est le genre de généralisation hative à éviter.
 

+1

oui c'est clairement mon problème avec ce système actuel. Mais tu fais comment concrètement ? genre une fonction qui génère un lien hypertexte, une fonction pour les tableaux(etc), et ensuite tu appelles ces fonctions pour constituer ta page ?
 

je trouve personnellement que concevoir ses objets en fonction des pages, c'est le meilleur moyen d'avoir une structuration incohérente et moins évolutive. Et (toujours personnellement), je préfère charger un objet dont toutes les méthodes ne seront pas utiles à la page demandée, mais qui me permet de savoir exactement de quoi se charge tel ou tel objet.
 
>anapajari : même avec les meilleurs codeurs du monde, une application en objet restera toujours un peu plus lourde niveau performance que son équivalent déclaratif, justement pour ces questions de charger en mémoire des objets dont tout n'est pas forcément utile à un instant t.  
D'ailleurs y a pas mal de gars qui sont complètement réfractaires à l'objet, avec pour argument que ça diminue les perfs  soi-disant pour avoir un code plus compréhensible par un  humain, point avec lequel ils ne sont pas d'accords (d'ailleurs j'avais lu sur ce forum la citation d'un mec qui en gros disait : l'objet, plus proche de la pensée humaine ? euh, dites moi quand est-ce que vous avez déjà réfléchi comme ça dans votre vie quotidienne ?)

Plus précisément:
1 page = 1 classe de base
Celà n exclu pas plusieurs classes héritées ou plusieurs sous-classes par classe de base.
 
Ton exemple est interessant:
L utilisation d une sous-classe IdentifiantEleve(id,nom), héritant de IdentifiantPersonne(id,nom), et appartenant à la classe Eleve(...), permet d instancier la classe Eleve afin d afficher la liste de liens vers les fiches élève à l aide de Eleve::afficher_lien() éventuellement réimplémentée de Personne::afficher_lien().

Pour la programmation fonctionnelle, c est pareil:
1 page HTML = 1 page PHP principale
Avec possibilité de pages PHP en include bien sûr.
 
Ça permet d éviter au serveur de traiter du code inutilement. Maintenant je dis pas que tout le monde le fait, et ça reste un choix à faire entre temps de developpement / fréquence et durée d utilisation du produit.

bah oui, mais là on parle de concept objet. Quand tu conçois un objet, tu fais en sorte qu'il représente un concept de ton domaine d'étude. Tu ne fais pas en sorte qu'il corresponde à une page html.
 
Et si demain tu modifies les infos d'une page, tu devras modifier tous les objets qu'il y a derriere, au lieu de juste modifier l'affichage. Y a un truc qui va pas.

C'est bien ce que je disais.
C'est un sac à fonction Djebel One a raison sur la reelle utilité d'un objet.

> Tu ne fais pas en sorte qu'il [un objet] corresponde à une page html.
 
Une page html est un objet. Si tu veux plus d abstraction de concept ou de multiples IHMs, t utilise une BDD objet.
 
> Et si demain tu modifies les infos d'une page, tu devras modifier tous les objets qu'il y a derriere, au lieu de juste modifier l'affichage. Y a un truc qui va pas.
 
Non, tu modifie juste la sous-classe concernée plutot que de naviguer dans les 2000 lignes d une classe obèse. Voire juste un template si c est purement graphique.

Pour moi une page html est une interface permettant de montrer ou manipuler des propriétés d'un ou plusieurs objets.
 
Pour moi un objet ne doit pas être purement graphique mais être logique, c'est à dire que l'ensemble de l'objet forme un bloc qui a une raison d'être. Je n'irais par exemple jamais faire un objet qui contiendra une discution d'un forum et le menu du site.

 
 
+10000
 

Je suis assez daccord.
pour m'aider a bien me structurer je m'aide de l'ensemble d'objet d'une structure de fichier et je me dit.
 
Un repertoire est fichier d'un type particulier : donc la classe repertoire herite de fichier
Un repertoire peut avoir des fichiers et ou des repertoires. les objets sont ressemblant mais chacun fait son taffe.
 
Quand j'ai reussie a monté ce diagramme ça m'a permis reglé pas mal de cas.

Donc au final, on est tous d'accord qu'un objet ne doit pas être conçu par rapport à la génération de l'affichage (sauf nargy).
 
Et il est vrai qu'au final, on peut se trimballer parfois avec de bons gros objets avec moultes méthodes, qui vont être instanciés en mémoire alors qu'on n'a pas besoin de toutes les méthodes à un instant t.
 
Je considère pour ma part que la structure du code et la conception des objets est au final plus importante que les considérations de performance.  
 
Mais, pour reprendre la question d'origine, comment faites-vous pour limiter l'influence négative d'objets trop gros, tout en conservant une structure objet correcte ? (moi ma réponse, c'est que je ne conçois pas les objets "performance wise", et qu'un script mal pensé jouera beaucoup plus sur les performances qu'une classe trop lourde, donc je ne m'inquiète pas trop de la lourdeur de mes classes)

EJ n'ai jamais eu de classes de 2000 lignes. Mais je sais qu'une requette SQL mal pensé ou une requette SQL sur une table mal indexé peut provoquer une lenteur bien plus importante que la simple lecture d'un gros fichier.
 
Le probléme de jamesbond2 vient peut être de là.

Je suis daccord surtout sur le dernier point.
Je pense que quand tu es sur que tes objet sont logique tu te preocupe pas de performance parce que normalement ça doit suivre.
 
Je me rappelle que dans la boite ou je travaillais il y avait un developpeur qui faisait une classe avec plus de 3000 lignes dedans.
Vl'a la maintenance quand il y avait un bug c'est simple il y avait quasiment que lui qui pouvait.  
C'est pour dire à cause de cette personne j'ai falli faire une depression nerveuse - arrête 1 semaine - (en sachant que je suis pas une chochote ) parce qu'il était partie en vacances et je devais reprendre son travail. C'est pour vous dire qu'une classe mal pensé peut vous emmeler les pinceaux par la suite, donc le reflexe c'est du faire des patch des reajustement de la magouille mais au final il y a l'effet boule de neige.

J'imagine bien la logique : "l'application est un objet => l'application est constitué d'une classe."    
 
Finalement, je me contente du code html de merde que m'a légué l'ancien webmaster. C'est surement moins douloureux.

moi je dois dire qu'en ce moment les classes de 2000 lignes, je connais malheureusement bien :  
je dois analyser un fichier pour en retirer des infos concernant un concept. Concept représenté par un objet.
L'objet va donc gêrer le stockage des différentes infos pendant l'analyse du fichier, puis analyser et mettre en forme les données stockées, avant de les insérer dans une base de données.
N'oublions pas la gestion des recherches sur cet objet ! Bah t'arrives vite à 2000 lignes en fait

Si tu n a aucun héritage, c est pas de la programmation objet, c est similaire à un script utilisant des arrays (concept, maintenance, performance).