singleton, multiton, téléton

[Ter Rowan]

les amis, je n'en peux plus

j'ai cherché des exemples d'utilisation du singleton et en dehors des 50 tutoriaux qui utilisent tous l'exemple de la connexion à la base de données, je n'ai pas trouvé d'autres exemples (bon je n'ai pas cherché dans 50 sites non plus, au bout du 6eme, j'ai pété un câble)

Pouvez vous me donner des exemples ?

mon idée au départ est d'optimiser des requêtes, mais est ce le bon modèle ou dois je faire juste une liste, pour détailler :

je veux charger les caractéristiques des différentes personnes en présence.

Chaque personne (classe personne) possède une liste de caractéristique.
Unitairement, je lancerais une requête sur la table carac_perso avec la condition que id_perso = id_perso

Maintenant si j'ai 10 personnes, ça me fait 10 requêtes.

Je me suis donc dit, cherchons le moyen (modèle ?) de ramener les caractéristiques des 10 personnes par une seule requête (en sql, facile, "where id_perso in ( ... ... ....)"

mais voilà... en objet, on le représente comment ?



merci d'avance

[Sephi-Chan]

Je ne sais pas si le Singleton est la meilleure chose pour toi. Ce que tu présente ressemble plus à une Factory.
Ainsi, je verrais plutôt une classe Person disposant de méthodes d'instance qui te retournent des instances de Person…

Un petit exemple :

$users = User::find_by_all_by_id([ 1, 2, 3, 4 ]); # On va retourner un tableau contenant 4 objets User.

Je te dis ça en m'inspirant d'ActiveRecord (désolé…), qui est tout de même THE ORM. Je t'invite à lire ce guide, qui devrait te donner plein d'idées Active Record Query Interface.

J'ai découvert qu'il y avait une implémentation d'ActiveRecord pour PHP (je ne sais pas ce que ça vaut), ça te permettra d'y voir plus clair sur l'utilisation/implémentation.

Si tu voulais des exemples d'utilisation de singleton, désolé d'avoir été HS.


Sephi-Chan

[pascal]

Salut,

Lorsqu'on s'intéresse aux design patterns, on essaie de les claquer un peu partout. Pour le singleton, c'est la même chose...

Il y en a d'autres qui sont + intéressants dans le cadre d'un jeu, comme strategy. Je te laisse chercher pour les détails

A+

Pascal

[Ter Rowan]

Salut,

Lorsqu'on s'intéresse aux design patterns, on essaie de les claquer un peu partout. Pour le singleton, c'est la même chose...

Il y en a d'autres qui sont + intéressants dans le cadre d'un jeu, comme strategy. Je te laisse chercher pour les détails

A+

Pascal

mais qu'il est vilain, qu'il est vilain !!!

pour la factory je l'envisage mais pour moi la factory serait plutôt dans la génération du résultat (une fois la requête faite) pas pour créer la requête
mais c'est peut être là où je fais plus compliqué que nécessaire

bon je vais regarder tout ça

merci

[pascal]

Chuis pas un vilain !

C'est juste que singleton, c'est cool pour un cours, dans la pratique il y a plus intéressant à mettre en oeuvre.

A+

Pascal

[Allwise]

J'utilise régulièrement le singleton pour des objets qui ne peuvent être instanciés plus d'une fois ( c'est la définition même du singleton ), par exemple dans une appli web riche pour laquelle toute l'interface graphique était rendue via un objet javascript, cet objet était déclaré singleton car l'interface graphique ne pouvait être affichée ( et donc instanciée ) plus d'une fois, ça n'aurait pas eu de sens.
Je l'utilise également dans des applications qui sont très centrées sur l'utilisateur connecté. Un petit currentUser::getInstance(), utilisable à tout moment est bien pratique. Ca retourne un objet avec toutes les caractéristiques de l'user. A côté, j'ai une classe user avec les traditionnelles méthodes qui manipulent les users : getUserByxxx, delete, save...
Cette classe est appelée dans le currentUser.

Pour ton problème je verrais bien 2 classes :
- une classe user, avec en attribut toutes les caractéristiques d'un user
- une classe avec, comme attribut, un tableau d'objets $users et qui aurait pour clé l'identifiant des dits users. Et en méthode, tout ce dont t'as besoin pour manipuler tes users mais surtout un getUsers(array $userIds) qui n'envoie la requête que si les identifiants n'existent pas en tant que clé de notre attribut $users. Et dans ce cas, ça ne récupèrerait que les users qui ne sont pas dans le tableau.
J'sais pas si je suis clair, c'est tout simplement une relation de type 1-* entre les deux classes quoi, et ça s'apparente à une factory.

[Ter Rowan]

et voilà j'en était sûr, je suis allé sur le singleton alors que j'étais tout près dans un précédent développement, grosso modo je construis une collection de user et voilà (voir factory si j'ai plusieurs classes différentes user je pense)

merci à tous

[DragonMaster]

Les design patterns sont des guides, bon c'est vrai que ceux du GOF sont très souvent directement applicable...mais j'aime bien imaginer qu'il y a toujours moyen de les adapter à nos besoins...et souvent on les utilises même sans s'en rendre compte. Un guide pratique vrai, mais je pense qu'entre connaitre les designs patterns et apprendre à faire une bonne modélisation...la seconde option est plus utile à long terme.

Ok je suis un peu HS...je cherche que des raisons pour repoussé mes travaux...