Discussion :

[koala01]

Salut,

On estime généralement qu'il faut encapsuler autant que possible les différents membres des classes et structures...

Cependant, il se peut qu'une classe contienne un certain nombre de membres dont il apparait opportun de les déclarer constant dés le départ, car force est de constater qu'ils ne doivent jamais être modifiés

Le nom et le prénom d'une personne, par exemple, sont sensés la suivre du jour de sa naissance au jour de sa mort: Hormis quelque cas médicaux qui font que Roméo devienne Juliette (ou inversement), il n'y a visiblement pas lieu de permettre le changement de nom ou de prénom.

Les fanatiques de "l'encapsulation à tous prix" nous ferons remarquer que l'on peut décider à tout moment de modifier la représentation de ces deux valeurs (qui sont au demeurant de même type) en mémoire, et donc qu'il est - à leur gré - préférable de les rendre privées, et de créer des accesseurs...

D'un autre coté, si, de fait, il est toujours possible *d'envisager* plusieurs moyens de représenter ces valeurs en mémoire, il ne me semble peu probable que quiconque n'en vienne un jour à décider de créer un tableau de chaines pour représenter le nom et le prénom d'une personne...

La question qui me trotte en tête est donc: est-ce que cela vaut réellement la peine d'encapsuler des membres constant dont on sait pertinemment que, au vu de la structure envisagée, une modification des détails d'implémentation n'a que peu de chances de survenir

[droggo]

Jea,

Pour moi, la réponse est incontestablement OUI.

Si on commence à briser le principe d'encapsulation pour ça, on trouvera bien un prétexte pour en faire de même pour d'autres données/fonctions...

Bref, la porte ouverte à la gabegie.

[koala01]

C'est *peut-être* un peu vite le contexte particulier que j'ai pourtant clairement exprimé dans lequel on se trouve...

Je conviens volontiers avec toi que la décision de "briser l'encapsulation" ne doit être envisagée qu'en marchant sur des oeufs, mais ici, il se fait que l'encapsulation ne semble a priori apporter aucune plus value...

Finalement que l'on écrive une structure sous la forme de

Code :

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

1
2
3
4
5
6
struct Personne
{
    const std::string nom;
    const std::string prenom;
    Personne(const std::string& n, const std::string& p):nom(n),prenom(p){}
};

(car c'est bel et bien de cela qu'il s'agit)
ou qu'on l'écrive sous la forme d'une classe proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Personne
{
    public:
        Personne(const std::string& n, const std::string& p): mnom(n), 
                   mprenom(p){}
        const std::string& prenom() const{return mprenom;}
        const std::string& nom() const{return mnom;}
    private:
        const std::string mnom;
        const std::string mprenom;
};

quelle plus value peut on trouver à la classe par rapport à la structure

[Laurent Gomila]

La théorie c'est beau, mais parfois il faut creuser un peu plus avant de se poser certaines questions.

En l'occurence, même si c'est joli au niveau conception, les membres constants sont très rarement (voire jamais) utilisés dans ce contexte. En effet que se passe-t-il si tu veux que ta classe personne soit affectable ? Si tu veux pouvoir charger ses informations à partir d'un fichier ? En fait, les membres qui sont vraiment constants sont rarement ceux que l'on expose via un accesseur.

Donc pour moi la question ne se pose pas ; en tout cas j'ai pu programmer jusqu'à aujourd'hui sans me la poser

[koala01]

La théorie c'est beau, mais parfois il faut creuser un peu plus avant de se poser certaines questions.

ici, c'est plutôt le contraire... c'est justement parce que j'ai creusé que... j'ai atterri en Chine

En l'occurence, même si c'est joli au niveau conception, les membres constants sont très rarement (voire jamais) utilisés dans ce contexte. En effet que se passe-t-il si tu veux que ta classe personne soit affectable ? Si tu veux pouvoir charger ses informations à partir d'un fichier ?

En bon théoricien, je lis le fichier, je sépare les différentes informations, et j'attends d'en avoir assez pour construire mon objet ... Non

En fait, les membres qui sont vraiment constants sont rarement ceux que l'on expose via un accesseur.

Justement...

Dans l'exemple que je cite, on se rend compte que:

• l'un des services de la classe est de fournir un acces en lecture seule sur la donnée
• cette donnée n'a aucune raison objective de changer entre le moment de la création de l'instance et le moment de sa destruction
• Le service autorisé par cette variable est... de permettre de répondre à la question "quel est ton nom"... ce qui est le but de la variable

D'ici à dire que l'encapsulation n'apporte aucune plus value, il n'y a qu'un pas... que j'hésite à franchir (d'où ma question )

Donc pour moi la question ne se pose pas ; en tout cas j'ai pu programmer jusqu'à aujourd'hui sans me la poser

C'est encore une fois la preuve qu'il est possible de se poser de droles de questions... Mais je l'ai signalé dés le titre

[Jean-Marc.Bourguet]

Si tu concois ta classe comme un agregat de donnees -- et des qu'on parle d'accesseur et de mutateur, c'est la conception qui me semblee sous-jacente -- ca ne me gene pas du tout que tous les membres donnees soient publics.

On utilise alors le C++ pour implementer une structure de code qui n'est pas orientee objet, et ce meme si on utilise les moyens que le C++ offre qui servent principalement pour les conceptions orientees object (comme l'heritage ou l'utilisation de membres virtuels).