[Conception] Ajouter des stats sur une classe métier

Bonjour,

Une petite question de conception. Voila j'ai une classe metier qui nourrit des stats. Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public Class Films{   private String name; private String realisateur; private Type type;   ....   +setter/getter   public update (){   //Insert in base }

---

Voila sur cette classe je dois faire des stat dans ma table stats (+1 film , + 1 type comédie ...). Donc dans ma fonction update je met à jour ma table stats

Code:

---

1 2 3 4 5 6 7 8 9

public update (){ addFilm(); if (type equals (comedie)){ addComedie(); }   etc... }

---

Comment feriez vous ça ?

A) Des fonctions d'ajout de stats statiques
B ) Implémenter une interface qui défini toutes les fonctions de stats pour la classe Film (type pattern observer)
C) Utiliser une classe abstraite avec toutes les fonctions et leur code
D) La réponse D

Merci

Salut,

Personnellement, j'utiliserais une fonction à base de generics, qui accepterait un objet de type <? extends Film> si tu as plusieurs classes qui étendent celle-ci, sinon pas la peine de la paramétrer en générics, et j'appelerais cette fonction consécutivement à l'appel de la méthode d'insertion d'un nouveau film.

Ta méthode addFilm devrait te retourner le Film persisté, et ainsi, tu pourrais passer cet objet à ta méthode de stats. L'avantage, c'est que tu pourras alors faire évoluer tes stats comme bon te semble.

A+

Merci KiLVaiDeN pour ton intéressant avis. Donc si je comprends bien tu proposerais un truc simple du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public Class Films{   ....   public update (){   this.update new stats (this); }   }

---

Je trouve difficile de répondre à ta question en l'état.

S'il s'agit de rajouter un x dans la colonne comédie ou drame ou... du rang stats, c'est une curieuse base de données.

S'il s'agit de mettre à jour des stats à chaque modif, bin il faut refaire les calculs, non ?

S'il s'agit de faire des traitements en fonction d'un type de distraction, type que vous auriez concrétisé par une classe java (il y a plein d'autres façons) (surtout pour les distractions hi ! hi ! hi ! ), soit leur nombre est connu et relativement stable et je suggère le polymorphisme (add(Comedie comédie), add(Drame drame)...), soit cela dépend de configurations divers et je suggèrre les annotations ; les génériques sont bien s'il y a quelque chose de... générique.

Citation:

---

S'il s'agit de rajouter un x dans la colonne comédie ou drame ou... du rang stats, c'est une curieuse base de données.

S'il s'agit de mettre à jour des stats à chaque modif, bin il faut refaire les calculs, non ?

---

Plutot la 1ére solution. Pourquoi une base de donnée ne serait pas adapter dans ce cas ?
L'idée est simple c'est de connaître à tous moments un certain nombre de stats pré défini. Par exemple :
Combien avons nous de film en base ?
Combien avons nous de comédie / drame / ... ?
Combien avons nous d'acteur en base ?
Combien avons nous de réalisateur ?
Combien avons nous de réalisateur ayant réalisé 2 films ou plus ?
....

Donc je me répéte les stats sont connus (et ne changerons pas) donc pas besoin d'enregistrer l'évenement mais juste de l'agréger à sa ou ses stats correspondantes. L'avantage pas de table stats qui devient ingérable.

Citation:

---

S'il s'agit de faire des traitements en fonction d'un type de distraction, type que vous auriez concrétisé par une classe java (il y a plein d'autres façons) (surtout pour les distractions hi ! hi ! hi ! ), soit leur nombre est connu et relativement stable et je suggère le polymorphisme (add(Comedie comédie), add(Drame drame)...), soit cela dépend de configurations divers et je suggèrre les annotations ; les génériques sont bien s'il y a quelque chose de... générique.

---

Les types de distraction n'ont pas de classe c'est la classe Film qui posséde un ENUM de distraction. D'ou un gros switch sur l'enum pour alimenter les bonnes stats. c'est un peu contraignant

Citation:

---

Envoyé par Shivan

Plutot la 1ére solution. Pourquoi une base de donnée ne serait pas adapter dans ce cas ?
L'idée est simple c'est de connaître à tous moments un certain nombre de stats pré défini. Par exemple :
Combien avons nous de film en base ?
Combien avons nous de comédie / drame / ... ?
Combien avons nous d'acteur en base ?
Combien avons nous de réalisateur ?
Combien avons nous de réalisateur ayant réalisé 2 films ou plus ?
....

---

À oui je comprends mieux : en fait c'est une requête d'état que vous voulez faire sur la base de données, après chaque modification de celle-ci, de façon à avoir toutes vos stats à jour dans l'appli.

Citation:

---

Envoyé par Shivan

Les types de distraction n'ont pas de classe c'est la classe Film qui posséde un ENUM de distraction. D'ou un gros switch sur l'enum pour alimenter les bonnes stats. c'est un peu contraignant

---

C'est le switch qui te gène ?

J'imagine que dans votre table il y a aussi une sorte de marqueur de sorte de distraction ; peut être pourriez-vous instaurer une règle relationnelle entre le enum et ce marqueur, et ainsi vous passer du switch ?

Merci pour ta réponse gifffftane.

En base le enum est représenté comme un int2. Je ne vois pas ce qui pourrais m'eviter un switch.

Pour rendre cela plus propre je voulais implémenter un pattern observer. Ma classe film implémenterais observer et enregistrer des listener de stats (stats pour film , stats pour acteur ...)

En gros

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public Class Film implements observable(){   List<Observer> observers = new arrayList()<Observer>();   public update (){   this.update notifyobserver();   }   private notifyobserver(){   for (Observer observer : observers){   observer.addfilm(); observer.addRealisateur(film.getRealisateur())   }   }

---

Et dans la fonction update de mes observers de la reflexion pour trouver la fonction qui va bien.

Enfin bref c'etait qu'une idée mais finalement je trouve cela lourd pour pas grand chose. Quoi qu'il arrive je serais obligé d'ajouter de nouveau "observer.update("nom fonction stats",value);" quand j'aurais une nouvelle fonction. Al la rigueur la seule facilité c'est de pouvoir enregistrer facilement de nouveaux observer mais je n'en aurais surement jamais l'utilité.

Citation:

---

Envoyé par Shivan

Merci pour ta réponse gifffftane.

En base le enum est représenté comme un int2. Je ne vois pas ce qui pourrais m'eviter un switch.

---

Tu peux placer des attributs dans tes énums. Ils ont une valeur statique, mais cela me semble convenir pour ton cas. Il suffirait je pense que tu lui donnes la valeur de ton int2 et, soyons f1ous, de l'appeler int2, et ça devrait couler sans switch. Regarde Enum Types.

Citation:

---

Envoyé par Shivan

Enfin bref c'etait qu'une idée mais finalement je trouve cela lourd pour pas grand chose. Quoi qu'il arrive je serais obligé d'ajouter de nouveau "observer.update("nom fonction stats",value);" quand j'aurais une nouvelle fonction. Al la rigueur la seule facilité c'est de pouvoir enregistrer facilement de nouveaux observer mais je n'en aurais surement jamais l'utilité.

---

Tu as raison c'est complètement inutile de faire un système de listener lorsqu'il n'y a que un listener. (et que l'on est assuré qu'il n'y en aura pas un deuxième un jour). J'ai toujours un peu de mal à comprendre pourquoi tu fais ces stats, mais j'imagine que c'est les mystères des specs.

Bonne continuation.

ok merci pour tes réponses gifffftane