IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Question idiote sur l'accessibilité des membres constants


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut Question idiote sur l'accessibilité des membres constants
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #2
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    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.

  3. #3
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #4
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2003
    Messages : 10 651
    Par défaut
    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

  5. #5
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par Laurent Gomila Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #6
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    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).

Discussions similaires

  1. Amis DBAs : question idiote sur les perfs
    Par ZERS dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 28/09/2006, 09h45
  2. question théorique sur le stockage des données
    Par jp_rennes dans le forum Administration
    Réponses: 1
    Dernier message: 18/09/2006, 18h28
  3. Réponses: 1
    Dernier message: 06/09/2006, 08h57
  4. question idiote sur terme utilisé dans les offres
    Par coyott dans le forum Emploi
    Réponses: 4
    Dernier message: 24/08/2005, 17h16
  5. Question simple sur la libération des objets
    Par gibet_b dans le forum Langage
    Réponses: 2
    Dernier message: 12/07/2004, 10h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo