Discussion :

[koala01]

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

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

[koala01]

Pour la gesion de flux, je l'accorde, je l'avais completement oublié ... 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

[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...

[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.

[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 :

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

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

[Biozic]

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.

[Jack_serious]

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...

[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

[koala01]

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

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
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 )

[koala01]

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 :

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

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 , ou du moins, en membre static des classes dans lesquelles ils apparaissent

[JolyLoic]

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.

[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 )

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 :

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

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.

[JolyLoic]

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 )

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.

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.

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.

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.