C++ struct, membres de données publiques et héritage

Question

Est-il possible d'avoir des membres de données publics dans une classe/structure C++ dans certaines situations particulières ? Comment cela s'accorde-t-il avec l'héritage ? J'ai lu des avis sur la question, certains déjà exprimés ici.

http://stackoverflow.com/questions/952907/practices-on-when-to-implement-accessors-on-private-member-variables-rather-than http://stackoverflow.com/questions/670958/accessors-vs-public-members

ou dans des livres/articles (Stroustrup, Meyers) mais je suis encore un peu dans l'ombre.

J'ai quelques blocs de configuration que je lis à partir d'un fichier (entiers, bools, floats) et j'ai besoin de les placer dans une structure pour une utilisation ultérieure. Je ne veux pas les exposer à l'extérieur, mais simplement les utiliser dans une autre classe (je veux en fait passer ces paramètres de configuration à une autre classe, mais je ne veux pas les exposer via une API publique).

Le fait est que j'ai beaucoup de paramètres de configuration de ce type (une quinzaine) et que l'écriture de getters et setters semble être une surcharge inutile. De plus, j'ai plus d'un bloc de configuration et ceux-ci partagent certains des paramètres. Faire une structure avec tous les membres de données publiques et ensuite sous-classer ne semble pas correct. Quelle est la meilleure façon d'aborder cette situation ? La création d'une grande structure pour couvrir tous les paramètres constitue-t-elle un compromis acceptable (je devrais laisser certains de ces paramètres définis) ? devrais laisser certains de ces paramètres à leur valeur par défaut pour les blocs qui ne les utilisent pas) ?

Answer 1

Si vous avez une structure de données qui n'est pas destinée à avoir un comportement mais qui n'est rien d'autre qu'un pur struct au sens du C, en particulier si chaque instance de celle-ci n'est utilisée qu'en interne pour l'implémentation d'autres classes "appropriées", alors il est bon d'en faire une struct et ont des champs publics. Après tout, comme vous l'avez souligné, une fois que vous lui avez donné des fonctions d'accès get/set pour chaque champ, vous êtes de toute façon revenu à l'équivalent logique des données publiques.

Answer 2

J'écris généralement les fichiers de configuration de mes programmes en utilisant les tampons de protocole de Google. Les getters et setters (parmi de nombreuses autres fonctions utiles) sont générés pour vous, comme dans un struct. Cela rend également l'édition de vos fichiers de configuration triviale, en permettant de nommer et de regrouper les champs de manière évidente.

http://code.google.com/apis/protocolbuffers/

Answer 3

Si la classe à laquelle vous voulez accéder aux données internes hérite de votre classe principale, vous pouvez définir les éléments suivants protected vous ferez ce que vous voulez. Si vous voulez qu'une autre classe non apparentée y ait accès, vous devez faire en sorte qu'ils friend s.

Answer 4

On dirait que vous avez juste besoin de faire ces membres protected - de cette façon, ils sont accessibles aux classes dérivées mais ne sont pas publics.

Answer 5

Le fait est que j'ai beaucoup de paramètres de configuration de ce type (une quinzaine) et que l'écriture de getters et setters semble être une surcharge inutile.

Ce problème peut être résolu de manière élégante par une macro. C'est la solution que je recommande.

Preuve de concept :

#define MAKE_ACCESSOR(type, name) \
    private: \
        type _##name; \
    public: \
        type const& name() const { return _##name; } \
        void name(type const& new_value) { _##name = new_value; }

…

class foo {
    MAKE_ACCESSOR(int, x)
    MAKE_ACCESSOR(int, y)
};

#undef MAKE_ACCESSOR