Discussion :

[Ehonn]

Lorsque j'ai écrit cible.nomPersonnage() j'ai supposé que tu avais un getter sur m_nomPersonnage dans la classe Personnage qui s'apellait nomPersonnage().

Voici le code du getter en question :

Code :

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

1
2
std::string const & Personnage::nomPersonnage() const
{ return m_nomPersonnage; }

Comme tu définis une fonction membre de la classe Personnage, tu as le droit d'écrire directement cible.nomPersonnage, mais c'est déconseillé. Il faut mieux passer par le getter.

[ternel]

Ce n'est pas que ce soit déconseillé, c'est complètement à l'encontre de l'essence même des classes.

Les classes sont une évolution des structs pour répondre au besoin d'encapsulation.

Le membre a tout intérêt à être privé tandis que l'accesseur constant (const string & nom() const;) sera public.
Ainsi, nulle fonction ne pourra modifier le nom du personnage, sauf si c'est une méthode de personnage, justement.

D'ailleurs, puisqu'il s'agit de la classe personnage, il n'est pas utile de nommer la fonction nom_personnage(), on le sait déjà:
personnage.nom() est assez clair, personnage.nom_personnage() est redondant.

[PilloBuenaGente]

Désole Garwan50 de voler une place dans ton message :p

Code :

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

1
2
std::string const & Personnage::nomPersonnage() const
{ return m_nomPersonnage; }

est-t-il égale à

Code :

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

1
2
const std::string & Personnage::nomPersonnage() const
{ return m_nomPersonnage; }

? Et les deux const ensembles ? Ça ne sert qu'a s'assurer que la string ne sera modifiée ?! Merci

PS Les fonctions commencent par une majuscule sont plus facilement identifiables. !?

[ternel]

C'est une bonne question technique.
const s'applique au type situé à gauche, ou à défaut, au type à droite.

Cela devient important avec les pointeurs:

• int* pointeur modifiable sur un int modifiable
• int* const pointeur constant sur un int modifiable
• int const * ou const int * pointeur modifiable sur un int constant
• const int* const pointeur constant sur un int constant

Une référence étant une sorte de pointeur constant "prédéréférencé", il ne peut pas y a voir de int & constTu peux rencontrer de manière équivalent const int & et int const&.

[Garwan50]

Bon j'avais eu un soucis mais j'ai réussis a le résoudre.
Merci c'était simple et une fois de plus je n'y est pas pensé ^^.
Vous gerez !

Pour l'encapsulation j'ai fait un getm_nom, avec un std::string (je précise parce que j'avais mis void au début, du coup avec le return a la fin il a pas aimé :p)

[Ehonn]

Fait attention avec les noms de variables et de fonctions.
personnage.getm_nom() est vraiment moche, personnage.nom() est le plus logique.

Pour les noms d'attributs, j'ai mis m_nom pour pouvoir laisser le nom logique au getter (nom()).
Un autre avantage et de donner un petite information au développeur; j'utilise m_ pour membre, r_ pour les références, s_ pour les membres statiques, p_ pour les pointeurs (très très très rare).

Autre point, le but de l'encapsulation est de "cacher" l'implémentation de la classe au programmeur qui utilise la classe. Certains vont même jusqu'à dire que retourner une référence sur membre constant (T const &) dans un getteur donne trop d'information sur la classe à ce programmeur. En ce sens, l'utilisation du nom getm_nom pour un getteur est vraiment abusé ^^

[koala01]

Certains vont même jusqu'à dire que retourner une référence sur membre constant (T const &) dans un getteur donne trop d'information sur la classe à ce programmeur. En ce sens, l'utilisation du nom getm_nom pour un getteur est vraiment abusé ^^

Là, tu exagères un tout petit peu quand même

Ce que l'on dit, c'est qu'il faut tenter le plus possible de respecter la loi de déméter.

Cette loi s'exprime, à peu près sous la forme de

Si tu utilises un objet de type A qui manipule en interne un objet de type B, tu ne devrais pas avoir à connaitre le type B pour manipuler ton objet de type A

Autrement dit, si l'objet que tu manipule utilise en interne un objet de type Position (ou Point ou n'importe quoi d'autre), tu n'as, a priori, pas besoin de savoir ce qu'est une Position, un Point ou ... pour pouvoir manipuler ton objet.

un code proche de

Code :

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

1
2
3
4
5
6
7
class MyClass
{
    public:
        Position const & postion() const{return position_;}
    private:
        Position position_;
};

ou, pire encore, un code proche de

Code :

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

1
2
3
4
5
6
7
8
class MyClass
{
    public:
        Position const & postion() const{return position_;}
        void setPosition(Position const & newPos){position_=newPos;}
    private:
        Position position_;
};

contrevient à la loi déméter car tu te trouves dans une situation dans laquelle tu est obligé de connaitre le type Position pour pouvoir manipuler ton objet de type MyClass.

La solution que l'on conseille est de faire en sorte que l'utilisateur de MyClass ne doive utiliser que des types les plus simple possibles (comme des types primitifs ou des classes "très bas niveau" comme une chaine de caractères) et que la gestion du type Position (dans le cas présent) se fasse en interne de manière totalement transparente à l'utilisateur

Ainsi, nous préférerons un code proche 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
class MyClass
{
    public:
        /* permet de récupérer la valeur de l'abscisse à laquelle 
         * l'obje se trouve
         */
        int x() const{return position_.x();}
        /* permet de récupérer la valeur de l'ordonnée à laquelle 
         * l'obje se trouve
         */
        int y() const{return position_.y();}
        void move(int differenceX, differenceY)
        {
             position_= Position(x()+differenceX, y()+différenceY);
        }
    private:
        Position postion_;
};

Voire, si l'on attend de la part de notre type de pouvoir le déplacer vers une position bien précise (parce que l'on récupère un objet de type Position "par ailleurs"), quelque chose comme

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
class MyClass
{
    public:
        /* permet de récupérer la valeur de l'abscisse à laquelle 
         * l'obje se trouve
         */
        int x() const{return position_.x();}
        /* permet de récupérer la valeur de l'ordonnée à laquelle 
         * l'obje se trouve
         */
        int y() const{return position_.y();}
        void move(int differenceX, differenceY)
        {
             position_= Position(x()+differenceX, y()+différenceY);
        }
        void moveTo(Position const & newPos)
        {
             position_=newPos;
        }
    private:
        Position postion_;
};

L'avantage que l'on en tire, c'est que chaque fonction publique de la classe indique très précisément ce qu'elle fait, et dans quelle circonstances il faut l'utiliser, sans rendre nécessaire la connaissance d'un type supplémentaire.

En effet, si on décide d'avoir recours à moveTo, c'est très clairement parce que l'on dispose déjà d'une position qui a été calculée, évaluée ou récupérée "par ailleurs"

[Ehonn]

Là, tu exagères un tout petit peu quand même

J'ai jamais dit que j'étais d'accord avec eux
Ceux qui disaient ça, mélangeaient clairement le coté technique et le coté juridique. Ils ne voulaient absolument pas donner d'information sur l'implémentation possible de leur bibliothèque.