Méthode d'affichage et prob de const

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/01/2008, 13h31
koala01

Oui, mais, dans ce cas là, est ce que la création du cache sera dévolue à une méthode constante :question:

Selon toute vraissemblance, il y aurait, à mon sens, deux classes entrant en jeu, chacune ayant sa propre responsabilité:
une classe "cache" avec une méthode (non constante) "create", recevant éventuellement (car elle peut etre un membre de la classe;)) la liste des éléments à utiliser pour créer le cache, et une autre "élément" qui aura un (ou plusieurs) accesseur(s) cohérent(s) avec les informations nécessaires pour la création du cache, qui sera (seront) une (des) méthode(s) constante(s)...

La méthode "create" de "cache" se chargeant d'appeler l' (les)accesseur(s) (constant(s)) de "element" pour chacun des éléments à utiliser pour créer le cache, non :question:
08/01/2008, 13h41
koala01

Pour la gesion de flux, je l'accorde, je l'avais completement oublié :aie:... pour l'exemple de la fonction estDansleTopDix(), selon moi, il y aurait lieu de correctement séparer les responsabilités:
le gestionnaire de note d'une part (celui qui dispose du tableau de note) s'occupe du tri des notes, vraissemblablement lors de chaque ajout, d'ailleurs (histoirre de garder le tableau trié en permanence... maintenant, il faut peut etre voir s'il n'est pas plus opportun de le faire une fois de temps en temps: avant une recherche par résultat ;)) et la fonction estDansLeTopDix d'autre part se contenant de... rechercher dans le tableau qui sera alors passé... en tant que paramètre constant ;)
08/01/2008, 13h44
Jack_serious

Je suis d'accord.

Je vois bien le principe, mais j'aurais plutot tendance a deleguer le calcul de la moyenne a une methode/classe dediee pour ca, qui mettrait a jour le cache...
08/01/2008, 15h22
JolyLoic

Je ne vois pas forcément l'intérêt de créer une classe séparée simplement pour gérer le cache d'une valeur (ou à la limite, simplement associer le booléen de test et la valeur, dans ce cas, j'utiliserais probablement boost::optional). Mais si je le faisais, l'instance de cette classe cachant la valeur serait une donnée membre de ma classe, et il faudrait soit qu'elle soit mutable, soit qu'elle même possède des données membre mutable.
08/01/2008, 15h34
koala01
En fait, mon idée personnelle est même que l'éleve n'a normalement aucun besoin ni aucun droit de disposer de ses notes, et que donc, les notes devraient être gérées par "quelque chose d'autre".

C'est ce "quelque chose d'autre" qui se charge de maintenir la liste des notes (en mettant chaque note en relation avec l'élève qui l'a obtenue), de calculer les moyennes et de fournir la place que cette moyenne vaut au sein du groupe concerné.

L'élève peut s'adresser à ce "quelque chose d'autre" pour disposer d'une note particulière, de sa moyenne ou de sa position dans le groupe, mais en lecture seule, quoi qu'il arrive...

Ainsi, la méthode estDansLeTopDix serait sans doute implémentée sous la forme de
Code:

1 2 3 4 bool Eleve::estDansLeTopDix() const { return gestionnaire->Position(monid)<=10; }
et toutes les autres méthodes de Eleves permettant d'obtenir des informations sur ses notes seraient dans la même veine :P
08/01/2008, 15h47
Biozic

Citation:

Envoyé par koala01

L'élève peut s'adresser à ce "quelque chose d'autre" pour disposer d'une note particulière, de sa moyenne ou de sa position dans le groupe, mais en lecture seule, quoi qu'il arrive...

OK, mais pour avoir accès à la moyenne dans un système en lecture seule, tu es obligé de la recalculer à chaque accès. Pour garder la valeur de la moyenne en cache, tu es obligé d'avoir un champ non constant, c'est-à-dire mutable s'il doit être appelé à partir d'une méthode constante, que ce soit une méthode de la classe qui gère le cache ou une d'une classe qui la contient.
08/01/2008, 15h57
Jack_serious

Citation:

Envoyé par Biozic

OK, mais pour avoir accès à la moyenne dans un système en lecture seule, tu es obligé de la recalculer à chaque accès. Pour garder la valeur de la moyenne en cache, tu es obligé d'avoir un champ non constant, c'est-à-dire mutable s'il doit être appelé à partir d'une méthode constante, que ce soit une méthode de la classe qui gère le cache ou une d'une classe qui la contient.

La methode qui regenere le cache et recalcule les moyennes n'est pas constante dans ce cas.
Par contre les methodes pour acceder au moyennes le sont.

L'inconvenient c'est qu'il faut appeler la methode qui regenere le cache a la main...
08/01/2008, 16h14
koala01

Mais le cache ne doit être régénéré que quand on fournit une nouvelle note au système, et cela peut donc pleinement rentrer dans une méthode "AddNote(ideleve,idexam,resultat)", qui n'est pas constante... mais qui n'est accessible que par les profs ;)

En fait, et pour etre préci, je verrais bien des classes prenant la forme de

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
class GestionnaireVuParEleve
{
    public:
       GestionnaireVuParEleve();
       ~GestionnaireVuParEleve();
        size_t position(const IdEleve &) const;
        double moyenne(const IdEleve &) const;
        double resultat(const IdEleve &, const IdExam&) const;
    protected:
        /* toutes les données en cache, protected pour qu'elle soient
         * accessible par les méthodes de GestionnaireVuParProf
         */
};
class GestionnaireVuParProf: public GestionnaireVuParEleve
{
    public:
       GestionnaireVuParProf();
       ~GestionnaireVuParProf();
       void AddResultat(IdEleve &, const IdExamen&, const double resultat);
};
class Eleve
{
    public:
        Eleve(GestionnaireVuParEleve*, const IdExamen&);
        ~Eleve();
        /* méthodes (exclusivement constantes) d'interrogation 
         * sur le résultat de l'éleve concerné
         * + 1 méthode non constante pour indiquer qu'il a présenté un examen
         */
    private:
        GestionnaireVuParEleve gestionnaire;
        std::list<IdExamen> presente;
        IdEleve id; 
};
class Prof
{
    public:
        Prof(GestionnaireVuParProf*);
        ~Prof();
    private:
        GestionnaireVuParProf* gestionnaire;
};

où IdEleve et IdExamen sont les structures les plus adéquate pour représenter respectivement l'éleve et l'examen de manière unique, et où il n'est pas impossible d'envisager une classe mere commune entre Eleve et Prof (une classe Personne :question:)

Et, en y réfléchissant bien, GestionnaireVuParProf n'hériterait meme pas de GestionnaireVuParEleve, mais serait une composition avec déclaration d'amitié, les comportements de gestion du cache pourraient etre (en privé ou en protégé) dans GestionnaireVuParEleve et appelés uniquement par la méthode d'ajout de résultat (ou les besoins de récupération de résultats persistants après redémarrage du système:))

Ce qui donnerait les deux classes sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 class GestionnaireVuParEleve { friend class GestionnaireVuParProf; public: GestionnaireVuParEleve(); ~GestionnaireVuParEleve(); size_t position(const IdEleve &) const; double moyenne(const IdEleve &) const; double resultat(const IdEleve &, const IdExam&) const; private: /* toutes les données en cache */ void readFile(); void addres(IdEleve &, const IdExamen&, const double resultat); }; class GestionnaireVuParProf { public: GestionnaireVuParProf(GestionnaireVuParEleve*); ~GestionnaireVuParProf(); void AddResultat(IdEleve &, const IdExamen&, const double resultat); private: GestionnaireVuParEleve* gestionnaire; };
Avec de forte présomptions sur le fait que GestionnaireVuParEleve et GestionnaireVuParProf finissent sous la forme de singletons :P, ou du moins, en membre static des classes dans lesquelles ils apparaissent

08/01/2008, 20h02
JolyLoic

Citation:

Envoyé par koala01

Mais le cache ne doit être régénéré que quand on fournit une nouvelle note au système, et cela peut donc pleinement rentrer dans une méthode "AddNote(ideleve,idexam,resultat)", qui n'est pas constante... mais qui n'est accessible que par les profs ;)

L'idée est de ne pas régénérer le cache à chaque ajout, mais uniquement à la demande. Parce qu'on va peut-être faire 50 ajouts avant de faire une demande, voire on ne va jamais demander. Si jamais on demande un jour. Or la demande est naturellement une opération constante, et elle va modifier l'état du cache. L'alternative consiste plutôt à mon avis à demander à l'utilisateur de la classe de gérer lui même l'état du cache, avec les risques que ça implique.
08/01/2008, 21h41
koala01
Je crois au contraire que tu risque, dans le cadre d'une gestion de notes d'étudiants, d'avoir plus de recherches que d'ajouts (un ajout par éleve et par examen, contre combien de recherches possible :question:)

Et l'on pourrait meme alors déléguer la décision de recréer le cache apres la dernière introduction.
qui s'intégrerait en définitive la forme de
Code:

1 2 3 4 5 6 7 while( ajouter) { /* récupération des valeurs */ gestionnaire->addres(eleve,exam,resultat); } gestionnaire->UpdateCache();
(mais dans la méthode permettant au prof d'ajouter ses notes ;))

De telle manière, la création du cache se fait de manière régulière, tout en ne monopolysant pas des ressources inutiles, alors que c'est pour le refaire tout de suite après ;)

En effet, il faut garder en tete que, si l'éleve dispose de la moindre possiblité de modifier ses cote, il risque fort de le faire, ce qui n'est acceptable dans aucun cas.
08/01/2008, 22h32
JolyLoic

Citation:

Envoyé par koala01

Je crois au contraire que tu risque, dans le cadre d'une gestion de notes d'étudiants, d'avoir plus de recherches que d'ajouts (un ajout par éleve et par examen, contre combien de recherches possible :question:)

Possible. Dans mon cas, pour n ajouts puis m recherches, il y a 1 calcul seulement. Dans le cas où tu calcules à chaque ajout, il y en a n.

Citation:

Envoyé par koala01

Et l'on pourrait meme alors déléguer la décision de recréer le cache apres la dernière introduction.

C'est ce que j'appelais la méthode manuelle. Elle peut être risquée.

Citation:

Envoyé par koala01

De telle manière, la création du cache se fait de manière régulière, tout en ne monopolysant pas des ressources inutiles, alors que c'est pour le refaire tout de suite après ;)

Je ne sais pas trop ce que tu entends par régulier ou monopolisation de ressources. La solution à base de recalcule à le demande impose un overhead d'un bool et d'un test par rapport à la solution manuelle, mais on gagne en échange une plus grande clarté du code, et moins de risques de bug.

Citation:

Envoyé par koala01

En effet, il faut garder en tete que, si l'éleve dispose de la moindre possiblité de modifier ses cote, il risque fort de le faire, ce qui n'est acceptable dans aucun cas.

Peut-être, mais je la discussion ne portait pas pour moi sur ce point (et si tel était le cas, qui associe la classe élève avec du code que pourrait appeler élève physique ??), mais sur un cas typique d'utilisation de mutable pour implémenter un cache automatiquement mis à jour.

Voir 40 message(s) de cette discussion en une page