Vous le savez probablement, mais je ferais simplement ce qui suit :
class Person {
public:
std::string name() {
return _name;
}
void name(std::string value) {
_name = value;
}
private:
std::string _name;
};
Cette approche est simple, ne fait appel à aucune astuce et permet de faire le travail !
Le problème est que certaines personnes n'aiment pas préfixer leurs champs privés par un trait de soulignement et ne peuvent donc pas vraiment utiliser cette approche, mais heureusement pour ceux qui le font, c'est très simple :)
Les préfixes get et set n'apportent pas de clarté à vos API, mais les rendent plus verbeuses et la raison pour laquelle je ne pense pas qu'ils apportent des informations utiles est que lorsqu'une personne a besoin d'utiliser une API, si celle-ci a un sens, elle se rendra probablement compte de ce qu'elle fait sans les préfixes.
Une dernière chose, il est facile de comprendre qu'il s'agit de propriétés car name
n'est pas un verbe.
Dans le pire des cas, si les API sont cohérentes et que la personne n'a pas réalisé que name()
est un accesseur et name(value)
est un mutateur, elle n'aura qu'à le consulter une fois dans la documentation pour comprendre le modèle.
Même si j'aime beaucoup le C#, je ne pense pas que le C++ ait besoin de propriétés du tout !
73 votes
Cela pourrait être fait avec quelques macros. s'enfuit honteusement
0 votes
Je rends tout public et j'accède directement aux champs dans le cadre de l'interface publique de la classe. Si un champ doit vraiment être privé, je le fais précéder d'un trait de soulignement, mais on peut quand même y accéder s'il y a une raison impérative. C'est une mauvaise idée si vous avez des développeurs incompétents dans votre équipe qui en abusent. canards
7 votes
@Eloff : Rendre tout public est TOUJOURS une mauvaise idée.
8 votes
Ce concept n'existe pas ! Et vous n'en avez pas besoin non plus : seanmiddleditch.com/why-c-does-not-need-c-like-properties
2 votes
A) cette question est assez ancienne b) je demandais un sucre syntaxique, qui me permettrait de me débarrasser des parenthèses c) bien que l'article présente des arguments valables contre l'adaptation des propriétés, la question de savoir si le C++ "a besoin ou non" de propriétés est très subjective. Le C++ est équivalent à la Touring-machine même sans elles, mais cela ne signifie pas qu'avoir un tel sucre syntaxique rendrait le C++ plus productif.
0 votes
C'est vieux mais pertinent. La réponse acceptée actuellement n'est pas complète, envisagez d'en accepter une autre.
0 votes
Pour des raisons de débogage, il m'arrive de convertir une variable membre publique (ick) en un opérateur getter et setter nommé (en utilisant les techniques décrites dans les réponses). Trouvez le bogue, puis supprimez cette instrumentation. C'est une technique pratique pour traquer les bogues, mais pas quelque chose à laisser en place pour la production (imo).
0 votes
@Kaiserludi pas nécessairement, si tout est public et statique vous êtes en sécurité =))) {sarcastices fermés}
0 votes
J'ai bien peur que non. 4321
3 votes
Définitivement non.
1 votes
Non, mais d'autant plus qu'il s'agit d'une lecture seule.
const Foo& foo(): const;
0 votes
Cette question est assez ancienne. Je demandais un sucre syntaxique, qui me permettrait de me débarrasser des parenthèses, bien que l'article présente des arguments valables contre l'adaptation des propriétés, la question de savoir si le C++ "a besoin ou non" de propriétés est très subjective. Le C++ est équivalent à la Touring-machine même sans elles, mais cela ne signifie pas qu'avoir un tel sucre syntaxique rendrait le C++ plus productif.
2 votes
Il n'y en a pas, principalement parce que cet anti-modèle est insensé. Tout ce qu'il tend à faire, c'est contourner l'encapsulation. Mais il n'y a pas de mal à demander.
1 votes
@CinCout, je reçois actuellement HTTP 500 connexion refusée sur votre lien. Au cas où il ne s'agirait pas d'une panne passagère : web.archive.org/web/20170924162758/http://seanmiddleditch.com/