Discussion :

[r0d]

Bonjour à tous,

j'ai une question un peu bête, mais je suis curieux de savoir comment vous faites.

Voilà, prenons un exemple, j'ai une structure Point:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct Point
{
   int x;
   int y;
};

Maintenant je veux lui faire un constructeur qui prend un x et un y en paramètre. Je voudrais faire ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct Point
{
   Point( int x = 0, int y = 0 ) : x(x), y(y) {}
   int x;
   int y;
};

Mais bien évidemment, je n'ai pas le droit de faire ça. Il faut donc que je trouve un autre nom, soit pour les variables membres, soit pour les paramètres passés au constructeur.

Or, la sémantique est importante. Et dans mon cas, je veux que x et y restent en accès public.

Vous voyez ce que je veux dire? Comment résolvez-vous ce problème?

[wiztricks]

Je préfèrerais donner d'autres noms aux variables de la classe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct Point
{
   int c_x; // coordonnée en x
   int c_y; // coordonnée en y
};

Mais en général je préfère mettre déclarer des Setter/Getter "inline" pour toucher aux variables.
- W

[Lucien63]

Mais bien évidemment, je n'ai pas le droit de faire ça. Il faut donc que je trouve un autre nom, soit pour les variables membres, soit pour les paramètres passés au constructeur.

Je viens de tester ton code. Il compile sans problème aussi bien sous gcc que sous borland C++.
Donc a-t-on vraiment pas le droit ?

[3DArchi]

Je préfère aussi utiliser une notation me donnant la porté de mes variables:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct Point
{
   int m_x;
   int m_y;
	Point( int P_x = 0, int P_y = 0 ) : m_x(P_x), m_y(P_y) {}
};

Sinon, tu peux faire dans l'explicite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct Point
{
   int x;
   int y;
	Point( int x = 0, int y = 0 ) {this->x = x;this->y = y;}
};

Enfin, si tu veux pouvoir faire Point.x, alors change le nom des paramètres.
P.S.: ton code compile en effet sous gcc et VC++.

[wiztricks]

c'est vrai que cela compile et qu'on a peut être le droit... Mais côté lisibilité c'est pas top.
- W

[HanLee]

Bonjour à tous,

j'ai une question un peu bête, mais je suis curieux de savoir comment vous faites.

Voilà, prenons un exemple, j'ai une structure Point:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct Point
{
   int x;
   int y;
};

Maintenant je veux lui faire un constructeur qui prend un x et un y en paramètre. Je voudrais faire ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct Point
{
   Point( int x = 0, int y = 0 ) : x(x), y(y) {}
   int x;
   int y;
};

Mais bien évidemment, je n'ai pas le droit de faire ça. Il faut donc que je trouve un autre nom, soit pour les variables membres, soit pour les paramètres passés au constructeur.

Or, la sémantique est importante. Et dans mon cas, je veux que x et y restent en accès public.

Vous voyez ce que je veux dire? Comment résolvez-vous ce problème?

Moi j'fais bêtement comme ça.

Côté lisibilité, aucun problème, quand tu as des classes avec des fonctions membres qui ont des responsabilités triviales et directes.

[Luc Hermitte]

[Suis-je le seul à voir ce que tu veux dire ?]
Effectivement, il y a la solution de l'explicite -- que je n'aime pas du tout.

Sinon, il te faut trouver un autre nom à tes paramètres.
Par chance, le style de codage imposé le client (au taf') demande à ce que tous les paramètres soient post-fixés par des tirets-bas -- ce qui déroute un poil après la lecture de XC++.

[r0d]

Effectivement. Je parlais surtout de sémantique en fait: comment faire pour résoudre ce problème de manière à faire en sorte que le code reste sémantiquement correct. Par sémantiquement correct, je veux dire qu'à la lecture d'une ligne de code, il est possible de déduire le rôle de chaque variable sans avoir besoin de voir le reste du code. Ce point là est pour moi de plus en plus important.

Donc effectivement, il y a les notations préfixées qui résolvent ce problème. Moi j'utilise le 'm_' pour les variables membres et le tour est joué.

Mais dans le cas où l'on aimerait bien garder des variables membres en accès public, le 'm_' perd sa pertinence sémantique.

On peut aussi préfixer les paramètres. De la même façon, je trouve que l'on y perd en sémantique. Ou alors on préfixe systématiquement les paramètre des fonctions et constructeurs, mais là je trouve que c'est un peu lourd.

Les accesseurs également. Le fait de laisser une variable membre en accès public n'est pas totalement anodin du point de vue de la conception.

Bon, je vous avoue que ce n'est pas une discussion qui va révolutionner le c++ , mais comme je le disais, je crois qu'au plus on avance, au plus on se rend compte que la sémantique est importante. Et j'aime bien discuter de ce genre de questions

[Spout]

Pour moi, tes variables x et y qui sont passées en paramètres sont des variables locales et doivent être sémantiquement marquées tel quel, ainsi que les types de ces variables (comme pour toutes d'ailleurs ). Voir la convention de notation hongroise (un peu stricte mais pas bête). Voici ton code tel que je le ferais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
struct Point
{
   public:
      Point(const int l_ix = 0, const int l_iy = 0 ) : m_ix(l_ix), m_iy(l_iy) {};
      int GetX() const {return m_ix;};
      int GetY() const {return m_iy;};
      void SetX(const int l_ix) {m_ix = l_ix;};
      void SetY(const int l_iy) {m_iy = l_iy;};
   private:
      int m_ix;
      int m_iy;
};

Donc effectivement, il y a les notations préfixées qui résolvent ce problème. Moi j'utilise le 'm_' pour les variables membres et le tour est joué.

Mais dans le cas où l'on aimerait bien garder des variables membres en accès public, le 'm_' perd sa pertinence sémantique.

Les accesseurs également. Le fait de laisser une variable membre en accès public n'est pas totalement anodin du point de vue de la conception.

Effectivement, les variables membres d'une classe doivent être marquées d'un 'm_', mais je comprends quand tu dis que le caractère publique de la variable casse un peu tout... J'aurais alors tendance à te dire que aucune variable membre ne doit être publique mais doit être utilisée de l'extérieur via des accesseurs. Je ne suis pas un star de la conception, mais tu es arrivé au point d'avoir des variables membres publiques, c'est que ta conception n'est pas forcément la bonne. Mais ce n'est que mon point de vue.

[Luc Hermitte]

Mettre des accesseurs pour le principe de mettre des accesseurs est une faute de conception -- en particulier quand il y a systématiquement un couple d'accesseurs/mutateurs triviaux pour chaque donnée membre.

Si ta classe ne fait que contenir des données, il faut l'accepter, car telle est son interface publique: contenir des données.

C'est un sujet largement débattu sur le net.

Donc non, mettre des m_x, m_y partout n'est pas mieux.

[Je laisse de côté le débat sur la notation hongroise System]

[Spout]

en particulier quand il y a systématiquement un couple d'accesseurs/mutateurs triviaux pour chaque donnée membre.

Tu peux m'en dire plus?
Pour le reste je ne suis pas forcément d'accord. Si le but est d'identifier directement la portée, le type et le rôle d'une variable rien qu'en la voyant (ce qui pour moi au même titre que r0d, favorise la lisibilité et, le cas échéant, la reprise du code par une personne différente) je campe sur mes positions .
Comment peux-tu le faire en ne voyant qu'un x?

[JolyLoic]

Globalement, j'ai tendance à utiliser deux conventions de nommage :
- Pour les classes classiques, myX, myY (que je trouve moins agressif à l'oeil et quand on lit du code à voix haute que toute solution à base de '_')
- Pour les classes qui ne sont qu'un agrégat de données (en public donc), simplement x, y.

[koala01]

Salut,

Visiblement, le problème est plus de trouver une convention de nommage des paramètres que tout autre chose, étant donné qu'il est effectivement tout à fait légal de donner le même nom au paramètre du constructeur qu'au membre qui en prend la valeur...

Par contre, il est vrai que si tu te trouve avec un structure du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
struct Point
{
    int x;
    int y;
    Point(int x, int y): x(x),y(y){}  // aucun problème, c'est légal, et les
                                      // arguments gardent leur sémantique
    void doSomething(int x, int y); // (**)
};

tu va te retrouver confronté à l'ambiguité de x et de y dans la méthode doSomething...

Dés lors, ne pourrais tu pas envisager de préfixer les arguments de termes indiquant la sémantique de leur utilité

Ce pourrait être newX et newY pour les fonctions qui se contentent de remplacer les valeurs, multiplyX et multiplyX si la méthode va multiplier les valeurs, addX et addY pour les addition cmpX et cmpY pour les comparaisons, etc...

Voire, "tout simplement", étant donné que le nom de la méthode fournit normalement déjà la sémantique de ce qu'elle fait, paramX et paramY, qui ont l'avantage d'être "génériques" et qui permettraient d'éviter l'ambiguité sans nécessiter le recours au pointeur this...

Ou alors, je n'ai peut être tout simplement pas plus compris le problème que les autres

[Luc Hermitte]

a- Tu peux m'en dire plus?

b- Pour le reste je ne suis pas forcément d'accord. Si le but est d'identifier directement la portée, le type et le rôle d'une variable rien qu'en la voyant (ce qui pour moi au même titre que r0d, favorise la lisibilité et, le cas échéant, la reprise du code par une personne différente) je campe sur mes positions .
Comment peux-tu le faire en ne voyant qu'un x?

a- Comme je le disais, une petite recherche remonte quantité d'articles sur le sujet
http://www.javaworld.com/javaworld/j...5-toolbox.html
http://www.artima.com/forums/flat.js...6&thread=36312
...

Le truc est que l'abus d'accesseurs est le signe que l'on code à l'ancienne, dans un modèle où l'on n'a pas suffisamment confiance en les objets du système pour leur donner du travail à faire. Bref, on n'encapsule rien du tout, on agit en control freak qui ne supporte pas qu'un objet puisse manipuler ses données tout seul et nous cacher leur existence même.

b- Donc tu dis que les langages qui supportent nativement la notion de propriété sont à l'ouest, et qu'ils auraient mieux fait d'en rester à getXXX(), setXXX() plutôt que d'exposer un xxx (dont l'accès est régulé par le couple get/set) ?


L'OO c'est gentil, mais il ne faut pas en faire une religion qui s'attache à des rites syntaxiques plutôt qu'aux concepts clés (abstraction, LSP, ...).


Bref, je me range avec ceux qui estiment qu'ils ne faut pas faire semblant (car il ne s'agit que de faire semblant, et rien d'autre) d'encapsuler les membres d'une structure de donnée. Et quand c'est comme cela, jouer aux m_xxx ne fait qu'alourdir l'écriture. Pire, on dit "utilise ce détail d'implémentation qui s'apelle m_xxx", au lieu d'"une propriété qui s'apelle xxx".

PS: nulle part je vois juste x. Mais je vois toto.x -- il n'y a pas de with comme en Pascal.

[Spout]

To see why, consider that there might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX()'s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble.

Forcément, c'est plus parlant

PS: nulle part je vois juste x. Mais je vois toto.x

Je parlais autant des variables membres que des paramètres d'une fonction.

Ce pourrait être newX et newY pour les fonctions qui se contentent de remplacer les valeurs, multiplyX et multiplyX si la méthode va multiplier les valeurs, addX et addY pour les addition cmpX et cmpY pour les comparaisons, etc...

Voire, "tout simplement", étant donné que le nom de la méthode fournit normalement déjà la sémantique de ce qu'elle fait, paramX et paramY, qui ont l'avantage d'être "génériques" et qui permettraient d'éviter l'ambiguité sans nécessiter le recours au pointeur this...

+1 .
Attention toutefois aux noms de variables trop génériques (temp, var par exemple à l'intérieur d'une fonction) qui ne facilitent pas beaucoup la compréhension du code

[wiztricks]

Il y a de la marge entre les différentes théories qui traînent et nos pratiques qui doivent aussi prendre en compte des spécificités d'un contexte.
Comme toute interface, les accesseurs utilisés à bon escient, ne sont ni bons ni mauvais.
Bien sûr, le "trop" devient rapidement "lourd", "risible"...
Et un sujet facile pour ceux qui aiment bien évangéliser

Je pensais que ce post questionnait nos pratiques et non nos croyances.
- W

[Spout]

Je pensais que ce post questionnait nos pratiques et non nos croyances.

Ne fais-tu pas l'un en fonction de l'autre?
Personnellement, ce post me fait prendre conscience qu'il doit y avoir un juste milieu entre les deux façons de voir évoquées ici de manière à ne pas rendre le code archi-lourd, donc pas lisible, donc pas maintenable.
Je me coucherais moins bête ce soir

[3DArchi]

Je rajouterais que les réponses à ces questions dépendent aussi du contexte au quel elles s'appliquent. Les choix ne seront pas les mêmes pour une petite appli perso, pour du code que l'on souhaite publier en libre, pour du soft dans un boite qui fait du soft, pour du soft dans un boite qui fait autre chose, sur un projet limité dans le temps, sur un projet qui doit être maintenu, sur un projet à 2 développeurs et 2 mois/homme, sur un projet à 15 développeurs et 2M€, etc...
Pour en revenir à la question de base, je serais partisan de laisser 'x' et 'y' dans la définition de la classe, mais préfixer les paramètres. Je trouve que cela facilite la lecture.

[wiztricks]

Ne fais-tu pas l'un en fonction de l'autre?

J'ai appris que les réalités étaient têtues.
Arriver à produire un code qui fonctionne n'est déjà pas si mal même s'il présente quelques écarts avec ce que je pouvais initialement souhaiter.

Personnellement, ce post me fait prendre conscience qu'il doit y avoir un juste milieu entre les deux façons de voir évoquées ici de manière à ne pas rendre le code archi-lourd, donc pas lisible, donc pas maintenable.
Je me coucherais moins bête ce soir

Cette discussion est intéressante parce le problème initial a été décortiqué sous différents aspects qui montrent qu'il n'y a pas de solution "générale". Ceci dit, il va bien falloir produire le code un jour et donc prendre à ce moment là une décision "moyenne".
En ayant plus d'arguments pour peser le pour et le contre, nous pouvons le faire de façon non pas "plus intelligente" mais plus fondée.
- W

[screetch]

pourquoi pas avoir les parametres x et y et utiliser this->x et this->y pour les membres ? il me semble que la semantique de this->x et this->y est tout a fait claire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
struct Point
{
   int x;
   int y;
   Point(int x = 0, int y = 0) : x(x), y(y) { }
   void set(int x = 0, int y = 0) { this->x = x; this->y = y; }
}