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

[Alp]

Pour ma part, je partage ton point de vue koala. Après, ce n'est et ne démeure que mon avis.

Une classe (ou structure...) Personne est justement quelque chose qui est semblable à ce que l'on peut faire en C, point de vue code. A l'exception près que l'on pourra la dériver pour créer des Employés, des Sportifs et autres Programmeurs, par exemple.

Dans tous les cas, il ne me semble pas abusrde d'exposer publiquement une donnée qui remplit les conditions suivantes :

• elle est constante
• elle risque d'être très utilisée car elle est totalement caractéristique de la classe dans laquelle elle se situe --- au sens où c'est l'une des informations les plus importantes de cette classe
• en plus d'être constante, on ne peut pas vraiment donner de sens à une modification de cette information (à part les cas médicaux, comme tu le dis )

Après, comme je l'ai dit, on peut rester dans la mentalité "Encapsulation à tout prix" et traiter cette information comme n'importe quelle autre.
Toutefois, j'aime bien programmer comme je pense.

Enfin, as-tu pensé au mariage ? Le nom des femmes change souvent lors d'un mariage

[Jean-Marc.Bourguet]

Enfin, as-tu pensé au mariage ? Le nom des femmes change souvent lors d'un mariage

En France -- et en Belgique, ailleurs comme aux Etats-Unis me semble-t'il ce peut etre different -- le nom d'une femme ne change pas apres le mariage. L'usage est d'utiliser le nom de son epoux, mais ce n'est qu'un usage.

[Alp]

Certaines vont pourtant le changer à leur mairie. Enfin on est un peu Hors-Sujet

[koala01]

Certaines vont pourtant le changer à leur mairie. Enfin on est un peu Hors-Sujet

Ah, non, en Belgique, du moins, une femme mariée prend éventuellement le nom de l'époux, mais suivi de "née (nom de jeune fille)"

Elle reçoit en fait un deuxième nom, mais garde malgré tout le premier (mais bon, arretons là le HS)

[koala01]

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.

tu place l'accent sur le tous... Mais complétons un peu la structure avec, tiens une valeur susceptible de changer de temps en temps: le nombre d'enfants... voire, une référence sur les enfants qui sont à la personne.

Autant cela me parraitrait logique de laisser le nom, le prénom et la date de naissance dont l'expérience montre qu'il s'agit de données constantes intrinsèquement nécessaire pour représenter une personne publiques, autant, du fait des vérifications potentielles liées aux modifications à apporter sur le nombre d'enfants, j'aurais tendance à encapsuler la donnée afin d'éviter à l'utilisateur d'en faire n'importe quoi...

[Jean-Marc.Bourguet]

* Si tu as des choses que tu cherches a mieux maitriser, c'est que tu ne consideres plus ta classe comme un simple agregat avec des fonctions utilitaires. Dans ce cas-la, je mets tout en fonction membre.
* Je comprends ton point de vue en ce qui concerne les membres constants (remarque que je ne me suis pas limite a ceux-ci), mais je prefere avoir pour une classe une homogeneite dans la syntaxe utilisee pour acceder aux proprietes. Avoir p.nom et p.nbEnfants() me gene.

[koala01]

* Si tu as des choses que tu cherches a mieux maitriser, c'est que tu ne consideres plus ta classe comme un simple agregat avec des fonctions utilitaires. Dans ce cas-la, je mets tout en fonction membre.
* Je comprends ton point de vue en ce qui concerne les membres constants (remarque que je ne me suis pas limite a ceux-ci), mais je prefere avoir pour une classe une homogeneite dans la syntaxe utilisee pour acceder aux proprietes. Avoir p.nom et p.nbEnfants() me gene.

Ok... je comprends ton point de vue, et je lui accorde une valeur certaine, car je n'avais absolument pas envisagé le problème sous l'angle de l'homogénéité...

Les autres motivations restent bien sur attendues avec intérêt

S'agissant d'un opinon quelque peu philosophique, je ne clôture pas la discussion

[Jean-Marc.Bourguet]

Ok... je comprends ton point de vue, et je lui accorde une valeur certaine, car je n'avais absolument pas envisagé le problème sous l'angle de l'homogénéité...

Les autres motivations restent bien sur attendues avec intérêt

S'agissant d'un opinon quelque peu philosophique, je ne clôture pas la discussion

L'homogeneite syntaxique est tres importante, c'est ce qui permet l'utilisation des templates.

[Alp]

L'homogeneite syntaxique est tres importante, c'est ce qui permet l'utilisation des templates.

+1 sur ce point. C'est d'ailleurs un truc que je fais souvent remarquer.