Discussion :

[Invité]

Bonjour,

J'ai une question.
J'ai fait un classe, toute simple, qui n'est là que pour me simplifier un peu la tâche (c'est le but de la prog vous allez me dire). Voici le code :

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
class DrawableList : public sf::Drawable, public std::vector<sf::Drawable*>
{
    public:
        DrawableList() : Drawable(), vector<sf::Drawable>(), deleteAll(false)
        {}
 
        DrawableList(delAll) : Drawable(), vector<sf::Drawable>(), deleteAll(delAll)
        {}
 
        ~DrawableList()
        {
        if(deleteAll)
            for(std::size_t i(0) ; i < size() ; i++)
                delete (*this)[i];
        }
 
        void setDeleteAll(bool delAll)
        {
            deleteAll = delAll;
        }
 
        bool getDeleteAll()
        {
            return deleteAll;
        }
 
    private:
        void draw(sf::RenderTarget& target, sf::RenderStates states) const;
        // See 'sf::Drawable' in the SFML documentation.
 
        bool deleteAll;
};

La question est : vu que l'attribut 'deleteAll' est tout simple, qu'il n'y a aucune vérification ou opération quand on le modifie que de lui donner la valeur en argument, et aucune restriction pour obtenir sa valeur, est-ce grave si je le rend public ? Histoire de simplifier un peu la chose.
Parce que pour le coup cela n'aurait aucune différence entre faire monInstance.setDeleteAll(true) et monInstance.deleteAll = true. Si ? Je sais que, principe d'encapsulation, tout ça. Mais est-ce grave si je fais cette exception ?
Je suis en fait partagé entre mon côté pratique qui me dit "vas-y, rend-le public, ça ne change rien à part simplifier les choses" et mon côté "bon petit soldat" qui me rappelle que non, les attributs d'une classe doivent toujours être privés.

Merci d'avance pour vos avis.

[Bousk]

Salut,

non, les attributs d'une classe doivent toujours être privés.

Ha bon ? Depuis quand ?

Y'aurait bien plus à redire du reste de la classe que de mettre ou non cette variable public.

[Invité]

Depuis quand ? Moi j'ai appris comme ça.

Mais, heu..le reste de ma classe ? Quel est (ou quels sont ?) le problème ?

Si c'est à propos des constructeur, dans la vraie implémentation, il y en a un seul avec l'argument 'delAll' qui a une valeur par défaut à false (plutôt que d'avoir deux constructeurs). Là j'en ai mis deux pour que le code puisse fonctionner alors que toute la définition de la classe est à un même endroit.
Mais j'imagine qu'il y a plus grvae (je vois difficilement quoi

EDIT :
AH oui, j'ai oublié de mettre la définition de draw().

Code :

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

1
2
3
4
5
6
void draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    for(std::size_t i(0) ; i < size() ; i++)
        if((*this)[i])  // If the pointer at index 'i' is not null...
            target.draw( *((*this)[i], states) );
}

[bacelar]

Vous avez de bons reflexes de développeur.
La règle de ne pas mettre en public les attributs vient plus de la culture JAVA que C++.
Mais il faut avoir un certain recule sur toutes les règles.

Il faut comprendre que tout ce qui est public fait partie de l'interphase de service de votre objet.
Il est donc très difficile de revenir après dessus car cela un impact sur le code client de vos objets.

Il est donc primordial que les détails d'implémentation de votre classe soit invisible du code client.

Ce que vous présentez à l'extérieur de votre classe doit être très murement évalué.

Une classe comme Point qui ne stocke que les coordonnées d'un point peut facilement exposer directement ses membres car cela constitue une interphase raisonnable.

Un truc qui défrise avec votre classe, c'est qu'elle hérite déjà publiquement de "std::vector<sf:rawable*>", il est donc bizarre d'avoir besoin de ce genre de détail qui ne correspond à rien du point de vue de l'utilisateur et il peut faire sans ce détail.

[Invité]

Un truc qui défrise avec votre classe, c'est qu'elle hérite déjà publiquement de "std::vector<sf::Drawable*>", il est donc bizarre d'avoir besoin de ce genre de détail qui ne correspond à rien du point de vue de l'utilisateur et il peut faire sans ce détail.

Comment ça ? Mettons que l'on crée des sf::Drawable exprès pour mettre leurs adresses dans une DrawableList, et que par la suite leurs adresses ne sont QUE dans cette DrawableList. Il faut bien que celle-ci puisse libérer la mémoire si on ne veut âs de fuite ? De même, si au contraire on partage (pour diverses raisons...) un même Drawable dans plusieurs DrawableList (d'où le fait que l'on stocke des pointeurs et non les Drawable eux-mêmes), il ne faut au contraire pas libérer la mémoire en détruisant un des DrawableList, ou le programme crashera quand un autre essaiera d'utiliser le Drawable supprimé.
Exemple de situation répondant à ce cas :
Je crée un programme éducatif. Celui-ci est composé d'énigmes qui s'enchaînent les unes après les autres. Pour chaque énigme, j'utilise un DrawableList afin de simplifier les choses (c'est le but). Mettons que dans chaque énigme il y ait un bouton "Retour au menu principal". Inutile de créer le même 15 fois, oui ? Donc chaque DrawableList aura un pointeur vers un seul et même bouton qui ainsi, sera toujours au même endroit, fera la même chose etc. Pareil avec un éventuel bouton "Valider".

Après je ne sais pas si c'est ce que vous vouliez dire.

[bacelar]

C'est beaucoup trop casse-gueule votre machin.
Faites simple, parce que là, on n'est pas foutu de savoir qui est responsable ou pas de la libération mémoire.
Un petit conseil, débarrassez-vous très rapidement de ces pointeurs nus pour des pointeurs intelligents.
Vous verrez que vous vous prenez la tête pour pas grand chose.