Style de codage getters/setters C++

Question

Je programme en C# depuis un certain temps et je veux maintenant rafraîchir mes connaissances en C++.

Avoir la classe :

class Foo
{
    const std::string& name_;
    ...
};

Quelle serait la meilleure approche (je veux seulement autoriser l'accès en lecture au champ name_) :

• utiliser une méthode getter : inline const std::string& name() const { return name_; }
• rendre le champ public puisqu'il s'agit d'une constante

Gracias.

Answer 1

L'utilisation d'une méthode getter est un meilleur choix de conception pour une classe à longue durée de vie, car elle vous permet de remplacer la méthode getter par quelque chose de plus compliqué à l'avenir. Bien que cela semble moins nécessaire pour une valeur constante, le coût est faible et les avantages possibles sont importants.

Par ailleurs, en C++, c'est une très bonne idée de donner à la fois le getter et le setter d'un membre. le même nom puisque, à l'avenir, vous pourrez effectivement modifier la paire de méthodes :

class Foo {
public:
    std::string const& name() const;          // Getter
    void name(std::string const& newName);    // Setter
    ...
};

dans une variable membre unique et publique qui définit l'un des éléments suivants operator()() pour chacun :

// This class encapsulates a fancier type of name
class fancy_name {
public:
    // Getter
    std::string const& operator()() const {
        return _compute_fancy_name();    // Does some internal work
    }

    // Setter
    void operator()(std::string const& newName) {
        _set_fancy_name(newName);        // Does some internal work
    }
    ...
};

class Foo {
public:
    fancy_name name;
    ...
};

Le code client devra bien sûr être recompilé, mais aucun changement de syntaxe n'est nécessaire ! Évidemment, cette transformation fonctionne tout aussi bien pour les valeurs constantes, pour lesquelles seul un getter est nécessaire.

Answer 2

C'est généralement une mauvaise idée de rendre publics les champs non constants, car il devient alors difficile de forcer les contraintes de vérification des erreurs et/ou d'ajouter des effets secondaires aux changements de valeur à l'avenir.

Dans votre cas, vous avez un champ de type "const", donc les problèmes ci-dessus ne se posent pas. Le principal inconvénient d'en faire un champ public est que vous verrouillez l'implémentation sous-jacente. Par exemple, si à l'avenir vous vouliez changer la représentation interne en une chaîne C ou une chaîne Unicode, ou autre chose, alors vous casseriez tout le code client. Avec un getter, vous pouvez convertir l'ancienne représentation pour les clients existants tout en fournissant la nouvelle fonctionnalité aux nouveaux utilisateurs via un nouveau getter.

Je suggère toujours d'avoir une méthode getter comme celle que vous avez placée ci-dessus. Cela maximisera votre flexibilité future.

Answer 3

Soit dit en passant, en C++, il est quelque peu étrange d'avoir un membre de référence constant. Vous devez l'assigner dans la liste du constructeur. Qui possède la mémoire réelle de cet objet et quelle est sa durée de vie ?

Pour ce qui est du style, je suis d'accord avec les autres pour dire que vous ne voulez pas exposer vos parties intimes :-) J'aime ce modèle pour les setters/getters.

class Foo
{
public:
  const string& FirstName() const;
  Foo& FirstName(const string& newFirstName);

  const string& LastName() const;
  Foo& LastName(const string& newLastName);

  const string& Title() const;
  Foo& Title(const string& newTitle);
};

De cette façon, vous pouvez faire quelque chose comme :

Foo f;
f.FirstName("Jim").LastName("Bob").Title("Programmer");

Answer 4

Même si le nom est immuable, vous pouvez toujours vouloir avoir la possibilité de le calculer plutôt que de le stocker dans un champ. (Je réalise que c'est peu probable pour "nom", mais visons le cas général). Pour cette raison, même les champs constants sont mieux enveloppés dans des getters :

class Foo {
    public:
        const std::string& getName() const {return name_;}
    private:
        const std::string& name_;
};

Notez que si vous changez getName() pour renvoyer une valeur calculée, il ne pouvait pas renvoyer const ref. Ce n'est pas grave, car cela ne nécessitera aucun changement pour les appelants (modulo recompilation.)

Answer 5

Évitez les variables publiques, sauf pour les classes qui sont essentiellement des structs de style C. Ce n'est tout simplement pas une bonne pratique à adopter.

Une fois que vous avez défini l'interface de la classe, il se peut que vous ne puissiez jamais la modifier (à part la compléter), car les gens se baseront sur elle et s'y fieront. Rendre une variable publique signifie que vous devez disposer de cette variable, et que vous devez vous assurer qu'elle possède ce dont l'utilisateur a besoin.

Maintenant, si vous utilisez un getter, vous promettez de fournir certaines informations, qui sont actuellement conservées dans cette variable. Si la situation change, et que vous préférez ne pas maintenir cette variable en permanence, vous pouvez modifier l'accès. Si les exigences changent (et j'ai vu des changements d'exigences assez étranges), et que vous avez surtout besoin du nom qui est dans cette variable mais parfois de celui qui est dans cette variable, vous pouvez simplement changer le getter. Si vous rendiez la variable publique, vous seriez coincé avec elle.

Cela n'arrivera pas toujours, mais je trouve beaucoup plus facile d'écrire un getter rapide que d'analyser la situation pour voir si je regretterais de rendre la variable publique (et risquer de me tromper plus tard).

Rendre les variables membres privées est une bonne habitude à prendre. Tout magasin qui a des normes de code va probablement interdire de rendre publique une variable membre occasionnelle, et tout magasin qui a des revues de code va probablement vous critiquer pour cela.

Chaque fois que cela n'a pas d'importance pour la facilité d'écriture, prenez l'habitude d'être plus sûr.