Petite question de POO

Hello,

Question conne en POO.

Avec un exemple cela sera plus parlant :

2 tables simplifiées

  • user
    champs : user_id, user_name, …
  • invoice
    champs : invoice_id, user_id, …

2 objets découlant de ces tables

user
propriétés : user_id (numeric), user_name (string), all_invoice (tableau d’objet invoice)
méthodes : set_user_id, load, get_all_invoice
invoice
propriétés : invoice_id (numeric), user (object)
méthodes : set_invoice, load

Pour vous est-il plus propre de stocker dans la propriété user de l’objet invoice, une instance de user ou juste le user id ?
Perso j’ai toujours eu le réflexe de stocker une instance de l’objet user.

Alors c’est propre (enfin je trouve) et plus pratique au moment de récupérer les infos de l’objet invoice.
Mais…
Imaginons maintenant que ce client est 3000 factures.
Cela signifie que pour les 3000 objets invoice créé, l’on va créer 3000 objets user identiques… Là c’est moins drôle déjà.

La solution serait de rajouter une méthode set_user a la classe invoice et de tester au moment du load si la propriété user est bien un objet. Je trouve que ca allourdi un peu le bouzin mais je ne vois que cela.

Qu’en pensez vous ?
D’autres idées ?
Comment faites vous ?

Je ne pige pas trop le sens de ton problème, car pour moi il apparait assez évident qu’il ne faut construire qu’une seule instance de chaque user, et de les associer à une collection qui permettra de les récupérer à partir de leur identifiant unique.

Tes 3000 factures partageront ainsi la référence vers l’instance unique de ton utilisateur.

Pour une vision côté class user du truc, lorsque tu charges tes 3000 factures par la méthode get_all_invoice(), tu fais un set_user(this) sur chaque facture… Ou bien je n’ai pas bien pigé ton souci ?

ça va dépendre d langage utilisé.

avec un vrai langage objet, tu vas créer un objet user et définir toutes tes factures en tant qu’attributs de cet objet. et dans chaque facture, tu auras un pointeur vers ton objet user. chacune de tes factures pointera alors vers le même objet user.

dansun langage avec de l’objet mais pas trop quand même (php…), il va falloir bidouiller. par exemple en stockant dans ton objet facture uniquement l’id du user, et en faisant a coté un tableau users un table d’objets user dont les clefs sont les id. ce qui est moche.

Merci à vous deux pour vos réponses.
Le langage sera du PHP et donc c’est bien qui me semblait cela sera un peu crado.

Donc en gros j’ai le choix entre, stocker l’user_id dans l’objet invoice ou stocker l’objet directement.

Le problème de la première solution est le côté moins accessible de l’objet user à partir de l’objet invoice.
Le problème de la seconde est le fait d’avoir des traitements différenciés dans l’objet invoice selon si on le load en ayant déjà un objet user ou pas.
Je m’explique:

  • Si on load l’objet invoice à partir de la méthode get_all_invoice de l’objet user alors on appelle la méthode set_user et on lui passe l’objet.
  • Si en revanche on load l’objet invoice avec juste l’invoice_id alors il faut dans l’objet loader l’objet user.

Donc en gros la propriété user de l’objet invoice peut recevoir soit un ID, soit un objet, ce qui est uber dégueu, même si cela est possible en PHP.

Donc je pense prendre la première solution, celle de Rabban :crying:

J’ai tout bien compris ? :slight_smile:

Yep.
Si ton attribut user de la facture est censé être un objet, lorsque tu construis ta facture ou que tu la charges (*), tu “get” ton user par le user_ID (ce qui tombe bien, c’est la PK ^^). Mais “get” ne signifie pas “créer une nouvelle instance”. Par exemple (**) (attention, mode halarache), tu peux très bien à ce moment-là aller regarder dans une collection centralisée si ton user n’existe pas déjà. Et s’il existe, tu récupères cette référence, sinon, tu crées l’isntance à ce moment-là, mets à jour la collection et attaches la référence…

Analogie rapide pour prendre du recul, pense aux objets chainés: tu ne crées pas une nouvelle instance pour chaque parent, tu passes (ou pas) sa référence en paramètre du constructeur.

() ou que tu t’aperçois que user est unset ou que… <= pas forcément systématique ()
(
) ça dépend des specs et de ton besoin (
**)
(***) oui, j’insiste ^^

[quote=“Rabban, post:3, topic: 36883”]ça va dépendre d langage utilisé.

avec un vrai langage objet, tu vas créer un objet user et définir toutes tes factures en tant qu’attributs de cet objet. et dans chaque facture, tu auras un pointeur vers ton objet user. chacune de tes factures pointera alors vers le même objet user.

dansun langage avec de l’objet mais pas trop quand même (php…), il va falloir bidouiller. par exemple en stockant dans ton objet facture uniquement l’id du user, et en faisant a coté un tableau users un table d’objets user dont les clefs sont les id. ce qui est moche.[/quote]

Même si le pb est demandé pour php, je m’inscris en faux pour la proposition sur le vrai langage objet…

Faire pointer les deux objets entre eux c’est mal parce que ça créé des dépendances croisées qui n’ont pas lieu d’être… Pour moi stocker l’user id est la bonne approche. Après tu interroge ta collection de de user pour récupérer l’objet.

La vrai question quand même est de savoir si :

  • dans le code de l’objet user tu fait des traitement sur tes objets invoice ? Ou inversement ? ou tu a juste besoin de retrouver l’objet ?

OK donc je vais partir dans la création d’une collection et ne stocker que des ID dans les classes qui iront chercher au moment voulu leurs objets dans cette collection.

SirAkuse, à partir de l’objet user je ne fais que récupérer les factures, aucun autre traitements particuliers.

Merci à tous.