Bonsoir,

Développant depuis quelque temps en php, je me demandait ce qu'était le mieux entre utiliser des variables multiples

ex :
private nom;
private prenom
.....


OU utiliser un tableau associatif pour stocker les valeurs ?

Niveau généricité, la deuxième solution est largement mieux mais que faut il mieux utiliser ?

Merci de vos réponses......

ce qui va le mieux pour le type de variable et ce qui te plait le mieux. Pas de meilleur choix que celui que tu fais en y réfléchissant et sans se dire qu'il ne va pas changer à un moment

pour ceux que sa intéresse : j'ai fait un test temporel

$nb_occur=3000000;
$time_start = microtime(true);
for ($i=0 ; $i<$nb_occur; $i++)
{
// test
}
$time_end = microtime(true);
$time = $time_end - $time_start;
echo 'Durée : '.$time.' secondes<br/>';
echo 'unitaire : '.$time/$nb_occur.' secondes<br/>';

----> 1er test : get sur objet utilisant un tableau en passant sans passer par call

Durée : 3.7082459926605 secondes
unitaire : 1.2360819975535E-6 secondes


----> 2eme test : get sur objet utilisant un variable en passant sans passer par call
Durée : 4.4957540035248 secondes
unitaire : 1.4985846678416E-6 secondes

--> tableau plus rapide

----> 1er test : get sur objet utilisant un tableau en passant par call

Durée : 10.826879024506 secondes
unitaire : 3.6089596748352E-6 secondes

----> 2eme test : get sur objet utilisant un variable en passant en passant par call

Durée : 10.687669038773 secondes
unitaire : 3.5625563462575E-6 secondes



voila......

donc visiblement, l'accès sur un champ d'un tableau est plus rapide que l'accès a une variable dans le cas ou on utilise un accesseur standard.

__call remet les 2 méthodes à égalités.


Bon maintenant j'arrête de jouer.......

Le deuxième sujet de benchmark aujourd'hui…
Faut arrêter, si vous voulez de la performance, faut arrêter le PHP et se mettre au C. Vous voulez que je bench pour voir si c'est pas plus rapide ?

a la base c'était pas ça le sujet...... c'était juste par curiosité......

en ce qui concerne le C pourquoi pas et tant que l'on y est pourquoi pas du Cobol

haaa, haaa, haaa, … mais il y a aussi l'assembleur
Faudrait que je fasse un site en assembleur un de ces jours

haaa, haaa, haaa, … mais il y a aussi l'assembleur
Faudrait que je fasse un site en assembleur un de ces jours

Les tarés -_-

haaa, haaa, haaa, … mais il y a aussi l'assembleur
Faudrait que je fasse un site en assembleur un de ces jours

Les tarés -_-

Moi je partirais bien sur un site écrit avec des 0 et de 1 (encore un niveau en dessous de l'assembleur)

Pour en revenir au sujet initial, je dirais qu'il te faut utiliser le format qui correspond à tes données. Un objet a des attributs indépendants qui peuvent éventuellement êtres des tableaux, mais créer spécifiquement un attribut tableau pour rassembler des valeurs indépendantes, je n'en vois vraiment pas l'intérêt.

Ce n'est même pas une question de performance (je ne vois d'ailleurs même pas l'intérêt d'un bench, etj'aimerais bien voir le code que tu as testé, parce qu'il est évident pour moi qu'accéder directement à un attribut ira plus vite que d'accéder à un attribut de type tableau dont il faudra ensuite trouver le bon index pour retourner la valeur souhaitée), mais simplement de logique : un utilisateur a un nom, un prénom, etc. il a pas un tableau

Ou alors j'ai pas compris la question et tu parles de tableau indexé à la place d'un objet, ce qui irait effectivement plus vite, mais qui te prive de toutes les possibilités apportées par un objet (méthodes, héritage, etc.). A ce moment là encore, c'est plus une question de contexte que de performance.

Moi je partirais bien sur un site écrit avec des 0 et de 1 (encore un niveau en dessous de l'assembleur)

Bah c'est de l'assembleur codé à la main, rien de plus :-/

En gros la question initiale c'est doit on considéré une entité (personne) comme un ensemble de variables (variables séparées) ou comme une structure de données (tableaux).

Cela va dépendre, personnellement je préfères voir une entité comme une structure de données et travailler avec des tableaux.Gain en lisibilité des qu'il faut passer un ou des éléments en paramètre d'une fonction par exemple. l'inconvénient étant la lisibilité pour les autres si ta structure n'est pas bien définie ou expliquée.

Salut,

Oui en effet créer un tableau pour mettre des variable dedans n'a pas énormément d'intérêt.

En modélisation (UML ou autre) on s'attache a faire apparaitre clairement les attributs pour plus de clarté. Il est vrai qu'une classe avec une variable tableau n'a pas grand intéret dans un diagramme de classe sauf cas particulier.

Dans mon cas j'utilise un tableau associatif avec comme clé le nom de l'attribut. Seulement j'avait l'impression de rentrer en "contradiction" avec la modélisation en utilisant un type tableau.

Donc Ryle, pointer un élément du tableau revient a pointer une variable. Je ne parcours pas le tableau étant donnée que j'ai la clé.

Pour vous ressituer un peu, j'essaie de faire un développement le plus générique possible en apportant beaucoup d'importance au couche. L'utilisation d'un tableau me facilite beaucoup la tache.

En fait, de défini mes objets (structure, classe, attribut,....) dans un fichier xml.
Au chargement, j'ai une classe qui récupère les structure.
Ensuite j'ai une classe abstraite qui gère les comportement généraux des objets. Lors de l'instanciation d'un objet, elle calque la structure correspondante.
Ainsi toutes mes classes sont quasiment identiques hormis certain traitement.
Enfin j'ai une classe gérant la persistance des données. Pour insérer un objet dans une base, j'utilise ma classe de persistance qui prend mon objet en paramètre et juste mon objet.
Ma classe de persistance charge aussi la structure des tables depuis le fichier xml. Ainsi elle génère automatiquement mes requetes que ce soit insert/update/select automatiquement et quelque soit l'objet en paramètre.
J'utilise le même procédé pour mes collection. J'ajoute un filtre (ex : totalCmd > 200€) et il va me chercher les infos dans la bonne table. En retour, il me creer mes objets sur 1 niveau ou récursivement. Ainsi, si j'ai une table commande avec un numéro de commande et un numéro de client, lors du chargement, il va regarder les champs, il va voir que le numéro client correspond a un objet Client et il va le charger et ainsi de suite. Du coup, dans mon tableau de mon objet Commande, dans le champ idClient, j'aurai un objet et non plus une valeur.

Sinon pour le bench, j'ai utiliser un cas très simple :
un objet commande initialiser et charger. Cette objet commande a un attribut "totCmd";

par la méthode du tableau, mon get renvoyait :

return $this->tab['totCmd']

en passant par une variable :

return $this->totCmd

En ce qui concerne l'appel :

$test = $cmd->getTotCmd();

Mais je suis tout a fait d'accord que le bench n'a pas grand intéret étant donné que l'accèes est de l'orde de la micro seconde.

Mais quand il s'agit de créer une collection d'objet resultant d'une requete sur 10000 tuples qui renvoi 1500 tuples, le bench a déjà plus d'interet.

enfin voila......