Discussion :

[wamania]

Salut à tous

Je me pose une question plutot conceptuelle.
Je m'explique par un exemple.
Vous avez un bonbon à représenter.
Pas de soucis, une classe, des attributs (poids, volume, apport calorique )
Un bonbon est vu comme une entité.
Mais qd on a plusieurs bonbons, ça se corse
Comment représenter un groupe d'entité, sachant que ce groupe d'entité ne peut etre représenter par une autre entité ?(par exemple ici, pas le droit au sac de bonbon, ils sont en vrac)
J'ai pensé au namespace, avec des fonction addBonbon, delBonbon, changeBonBonToCachou....
Un classe peut bien sur etre envisagée, mais selon mes connaissances de POO, c'est pas vraiment le meilleur choix.
Qu'en pensez vous svp?

[Mr N.]

Crée une classe Collection ? Et pourquoi tu n'aurais pas le droit au SacDeBonbon ?

[wamania]

pas le droit au sac de bonbon car ça ne représente pas l'ensemble des bonbon.
Par exemple, le sac peut etre rouge, avoir un volume à vide, un poids à vide...mais ça ne m'avance pas pour le représentation de mon groupe de bonbon, au mieux, le dénominateur commun est le nombre de bonbon.
Par exemple poids total = poids du bonbon * nb de bonbon + poids à vide du sac.
On voit bien ici qu'aucune caractéristique n'est lié au groupement de bonbon, mais à un bonbon * n et au sac.
D'ou ma question comment représenter un groupe d'entité n'ayant aucunes caractéristiques intrinséques, mais possédant des caractéristiques composés des caractéristiques des autres entités?
Une classe est correcte niveau prog, mais d'un point de vue POO de puriste, je suis sur que la représentztion est mauvaise.

J'avoue, c'est plutot abstrait

[ePoX]

Perso sa me plait bien la collection.
Ton groupe de bonbon je le voit comme un amas de bonbon posé sur une table.
Et la collection c'est cela, N bonbons ensemble.

Après, l'histoire du sac, c'est un super groupe de bonbon, une collection avec des attributs supplémentaires.

[wamania]

oki oki
j'ai donc chercher un peu, trouver pas mal de chose en java, qqs portages simplifié sur PHP.
En gros, ça me rappelle les bonnes listes chainées de mon C++ natal.

Merci à vous 2

[Mr N.]

Par exemple, le sac peut etre rouge, avoir un volume à vide, un poids à vide...
[...]
Par exemple poids total = poids du bonbon * nb de bonbon + poids à vide du sac.

Là tu te mets des batons dans les roues. Quand tu vas chez le marchand de bonbons, tu te fiches pas mal de la couleur du sac et le poids de celui-ci est pris en compte lors du calibrage de la balance (heureusement sinon imagine les abus).
Quant tu traduit un objet du monde réel en objet dans ton code, tu as le droit de t'abstraire de certaines caractéristiques et ne garder que celles qui concernent ton besoin.
Ici la seule chose dont tu aies besoin et le fait qu'un sac peut contenir des bonbons. C'est tout. La couleur, le poids, la texture, le fabricant du dit sac, ton appli n'en a rien à faire alors que ça aura une importance chez quelqu'un d'autre.
L'avantage de prendre SacDeBonbons, c'est que c'est un représentant du monde réel et la conception s'en retrouve s'implifiée.

Exemple parmis d'autres (made in php4) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class SacDeBonbons {
   var $bonbons;
   function SacDeBonbons() {
      $this->bonbons = array();
   }
 
   function ajouter(&$bonbons) {
      $this->bonbons[] =& $bonbons;
   }
 
   function total() {
      return count($this->bonbons);
   }
}