Discussion :

[koala01]

Bonjour à tous ! J'aime beaucoup ce sujet ! Et les articles que Luc a cité sont très intéressants.

Toutefois, comme je suis un novice influençable, ça m'a mis le doute :

Si je construis une classe Complex toute bête pour représenter un nombre complexe et faciliter les calculs sur ces nombres, on est bien d'accord que je dois mettre mes membres re et im en public ?
Car contrairement aux cas évolués cités dans les articles donnés par Luc, je ne peux pas demander à ma classe complexe de faire tout le boulot pour moi, dans la mesure où je vais travailler avec des tableaux de Complex plus qu'avec les objets Complex eux-mêmes, et que ce qui m'intéresse c'est donc les 2 valeurs qu'ils contiennent.

Mais dans ce cas, l'intérêt d'utiliser un objet c'est essentiellement de pouvoir redéfinir les opérateurs, pas d'encapsuler.

Est-ce que j'ai tenu le bon raisonnement après avoir lu tous vos posts, ou bien suis-je à côté de la plaque ?

Voilà, petite question de débutant qui s'immisce dans votre discussion
Merci et bonne journée !

Raphaël

Ce qu'il y a de bien, en programmation, c'est qu'il n'y a pas de mauvaise méthode de faire... il n'y a que des méthodes qui présenteront certains avantages et / ou certains inconvénients.

Ainsi, pour ce qu'il en serait d'un type "Complex", trois possibilités sont présentes:

Soit, tu envisage le type Complex comme un "POD" (Plain Old Data) ou, si tu préfère comme "une simple structure qui regroupe plusieurs valeurs qui vont si bien ensemble", et tu te contente d'y adjoindre certaines fonctions qui fournissent les comportements attendus (comparaison, addition, multiplication, ...) dont l'avantage est de t'éviter d'avoir à réfléchir aux mutateurs/accesseurs nécessaires et de te permettre de te concentrer sur les fonctions indispensable (comparaison, opérations mathématique, ...) mais dont l'inconvénient réside dans le fait que, si une des variables qui le compose ne peut pas avoir une valeur particulière, tu va obliger l'utilisateur de la structure à effectuer les tests lui-même.

Soit, tu considère le type Complex comme "un tout immuable" une fois qu'une instance en a été créée, et tu encapsule les données en ne fournissant que les comportements constants que tu es en droit d'attendre du type.

L'avantage, c'est que tu limite énormément les manipulation hasardeuses par la suite.

L'inconvéniant, c'est que, si tu veux additionner (ou effectuer n'importe quelle opération mathématique entre) deux complexes, tu sera obligé de passer par la création d'un nouveau complex, dont les valeurs correspondent au résultat escompté... avec tous les petits inconvénients que cela peut occasionner en terme de copie et de création d'instances.

Soit, enfin, tu envisage un "mix" des deux solutions, en admettant éventuellement de créer des mutateurs pour les variables qui nécessitent une validation avant d'accepter les modifications de valeur, mais cela se fera au détriment de l'homogénéité globale de tes conventions d'appel: tu pourrais très bien en arriver à te trouver confronté à un code proche de

Code :

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

1
2
3
4
5
void foo(Complex & c, int i, float f)
{
    c.x*=i;
    c.setImaginaire(c.getImaginaire() * f);
}

avec l'éternel problème de savoir "si je veux modifier telle valeur, dois-je y accéder directement, ou passer par un mutateur "

Seule la situation à laquelle tu es réellement confronté te permettra de choisir "la moins mauvaise" des solutions, pour qu'elle puisse s'adapter à tes besoins réels (il est vrai cependant que la préférence ira sans doute à l'une des deux premières )

[Luc Hermitte]

@Estyros. Pour moi, l'intérêt d'un complexe, ce sont les opérations que l'on va définir dessus.
En particulier, on pourra accéder (lecture) à ses 4 propriétés (je n'ai pas dit "attributs") qui sont la re, im, r, et theta/rho.
Par contre, comme ça, je ne voit pas d'intérêt de pouvoir les modifier directement avec des set.
Un complexe est une valeur et pas une entité, si on veut modifier unitairement un champs, le mieux, AMA, est de créer un nouveau complexe, ou de passer par les opérations dédiées.

std::complex et boost::rational semblent avoir été définis selon cette même logique.

Quant à protégé/privé, quand j'ai le temps de faire propre, j'ai tendance à privilégier la données en privé, quitte à fournir un mutateur non trivial (ou pas de mutateur du tout), et un accesseur, tous deux protégés. Cela me donne un meilleur contrôle des invariants.

et donc des get/set.... non?

Potentiellement. Mais pas nécessairement. L'attribut appartient d'abord à la classe mère qui sera la mieux à même de maintenir ses invariants. En donnant un accès protégé (ou par set-trivial) aux attributs, j'ai l'impression d'exposer des détails internes (contrairement aux fonctions amies).
Parfois cela a du sens, (question d'interface de manipulation interne) mais j'y réfléchis bien avant.

[wiztricks]

Si je construis une classe Complex toute bête pour représenter un nombre complexe et faciliter les calculs sur ces nombres, on est bien d'accord que je dois mettre mes membres re et im en public ?

Histoire de faire hurler les lecteurs.

Un nombre complexe est une sorte de tableau de nombre réels (comme une chaine de caractères est un tableau): il s'agit de composition simples de type de bases...
Les opérations qu'on va vouloir réaliser avec/dessus sont souvent des extensions de celles qui sont réalisées avec les types de bases qui les composent.
Si la glue qui est à la base de cette composition (tableau, vecteur) est connu, stable, ... est-il utile d'en opacifier l'implémentation avec des get/set?

Plus généralement, un objet (au sens POO) définit lui aussi un type abstrait composé d'un aggrégat de plusieurs types de base ou de types complexes.
Il définit aussi un ou des rôles qui seront représentés par des méthodes spécifiques qui modifieront un certain nombre d'attributs "internes" (pensez employé, facture, produit,...)
Dans ce cas, la question de l'opacité ou de la transparence de certains attributs se pose complètement différemment. Pourtant ce sera toujours du code qui commencera par la déclaration class.

-W

[yan]

Donc si je suis ce que dit kaola01 :il y as trois type d'implémentation :
1- POD :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct CPoint
{
        CPoint(double x,double y) 
        :m_x(x),m_y(y)
        {
 
        };
 
       double norme()
       {
           return sqrt(m_x*m_x+m_y*m_y)
       }
 
       double m_x;
       double m_y;
}

2- immuable

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class CPoint
{
        double m_x;
	double m_y;
        double m_norme;
 
public
       CPoint(double x,double y) 
       :m_x(x),m_y(y)
      {
          m_norme =  sqrt(m_x*m_x+m_y*m_y);
      }
 
     CPoint(const CPoint &p) 
      :m_x(p.x()),m_y(p.y()),m_norme(m_norme())
      {
          m_norme =  sqrt(m_x*m_x+m_y*m_y);
      }
 
 
     const double & x() const {return m_x;};
     const double & y() const {return m_y;};
     const double & norme() const {return m_norme;};
}

3- un mixte

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
class CPoint
{
	double m_x;
	double m_y;
	bool m_calculerNorme;
	double m_norme;
public :
	CPoint(double x,double y) 
		:m_x(x),m_y(y),m_calculerNorme(true),m_norme(0.)
	{
	};
 
	void  initX(const double & x)  
	{
		m_calculerNorme = true;
		m_x = x;
		return m_x;
	}
	const double & x() const 
	{
		return m_x;
	}
 
	void initY(const double & y)  
	{
		m_calculerNorme = true;
		m_y = y;
		return m_y;
	}
 
	const double &y() const
	{
		return m_y;
	}
 
	const double & norme()
	{
		if (m_calculerNorme)
		{
			norme = sqrt(x()*x()+y()*y());
			m_calculerNorme = false;
		}
		return m_norme;
	}
};

chaqu'unes avec ses avantages et inconvénients. Je voulais alors vous demander qu'elle est celle que vous préférez?? et pourquoi (perf, lisibilité,...)?

[koala01]

Histoire de faire hurler les lecteurs.

Un nombre complexe est une sorte de tableau de nombre réels (comme une chaine de caractères est un tableau): il s'agit de composition simples de type de bases...
Les opérations qu'on va vouloir réaliser avec/dessus sont souvent des extensions de celles qui sont réalisées avec les types de bases qui les composent.
Si la glue qui est à la base de cette composition (tableau, vecteur) est connu, stable, ... est-il utile d'en opacifier l'implémentation avec des get/set?

Plus généralement, un objet (au sens POO) définit lui aussi un type abstrait composé d'un aggrégat de plusieurs types de base ou de types complexes.
Il définit aussi un ou des rôles qui seront représentés par des méthodes spécifiques qui modifieront un certain nombre d'attributs "internes" (pensez employé, facture, produit,...)
Dans ce cas, la question de l'opacité ou de la transparence de certains attributs se pose complètement différemment. Pourtant ce sera toujours du code qui commencera par la déclaration class.

-W

Et encore...

Le problème d'un client est qu'il sera représenté par certains invariants (sa référence, son nom, son prénom, sa date de naissance, ou son numéro TVA, par exemple) et par certaines variables (au sens : qui peuvent être modifiée "à tout moment" comme son adresse ou son numéro de téléphone), mais qu'il peut aussi devoir contenir certaines informations calculées et / ou déterminées de manière externes et restreinte dont le seul aperçu que l'on peut être une autorisation (ou une interdiction) de "mettre cela sur son compte":

Le montant total de la ligne de crédit peut être évalué en fonction du "chiffre d'affaire" (nouveau client, petit compte, compte moyen, grand compte, compte très important) effectué avec lui et de la régularité de ses payement (s'il paye plutot avant échéance, plutot juste à échéance, plutot en retard...)

Et l'autorisation de mettre "tel achat sur son compte" sera alors évaluée en fonction de son en cours actuel, de la ligne de crédit dont il dispose et du montant de l'achat à mettre en compte...

Si plusieurs personnes doivent accéder au client, on se rend compte que les services rendus par ce type abstrait de donnée sera différent:

Le service comptable pourra modifier la régularité de ses payements, diminuer son en-cours et accéder aux informations de facturations qui son propres au client,

Le service ayant en charge la décision des lignes de crédit autorisées ne pourra accéder que de manière informative à la régularité des payement, mais de manière active à la taille du compte.

Enfin, le service vente / clientèle ne pourra accéder de manière informative qu'à la réponse à "puis-je mettre cela sur le compte de monsieur" et de manière active, mais de manière limitée à l'en cours...

J'admets que dans de petites structures, une personne peut avoir "plusieurs casquettes" et que certains éléments abordés ici seraient plutôt à envisager dans de grosses boites...

Mais le but ici est de bien montrer encore une fois que les décisions "à l'emporte pièce" ne sont valables que dans la situation dans laquelle on les prend.

[koala01]

chaqu'unes avec ses avantages et inconvénients. Je voulais alors vous demander qu'elle est celle que vous préférez?? et pourquoi (perf, lisibilité,...)?

A vrai dire, par mixte, je voyais plutôt un code (qui ne rime à rien dans l'exemple, j'en suis conscient) proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class Point
{
    public:
        Point(double x, double y):x(x),y(y){}
        double x;// on laisse les gens le modifier à leur aise
        const touble& getY() const;
        void setY( double &);
        double norme() const{return  (x+y)/2;}
    private:
        double y; //mais on sécurise l'acces à y
 
};

Cela m'inciterais donc à ajouter une quatrième possibilité à celles que tu as résumée et qui serait la solution "muable" qui fournirait des mutateurs pour les membres et qui se rapproche donc ta solution "mixte"

A titre personnel, et dans le cadre d'une classe Point, je préfèrerais la solution immuable car il s'agit d'une entité ayant force de valeur qui n'exprime sa réelle utilité qu'au sein de la collection qui l'utilise.

Cependant, pour certaines classes plus complexes, je me tournerais vers le "juste milieu" entre la solution "immuable" et la solution "muable", en ne fournissant que les mutateurs pour les membres pour lesquels ce serait opportun (je parle de mutateur afin d'éviter le terme "setter", et me donner la possibilité de décider qu'un mutateur fait varier plusieurs valeurs "par lot" )

Je rejoins en effet l'avis donné par Jean-Marc.Bourguet dans une discussion passée selon lequel "l'homogénéité syntaxique" a une importance majeure, de manière à éviter à l'utilisateur de ma classe le problème de devoir retenir que telle valeur est accessible directement alors que telle autre nécessite le recours à un accesseur et / ou à mutateur

[HanLee]

Euh, et pourquoi pas ça :

Code :

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

1
2
3
4
5
6
7
class Point {
public:
    double x, y;
 
    Point() { }
    Point(double x, double y) : x(x), y(y) { }
};

Et que des fonctions libres auxiliaires (ou statiques) ?
Je trouve ça élégant, épuré.

Pour la const correctness et l'immuabilité, c'est parfait, il suffit juste de mettre un const au bons endroits...

J'aime particulièrement ce que cette page dit à propos des classes (sur GotW).

-----

@Mongaulois :

Sur cet exemple précis, le coup de la norme mise en cache c'est pas du tout adapté, parce que du coup ça fait une optimisation prématurée et contre productive en plus.

Niveau mémoire, on se trimbale beaucoup de choses pour rien. Niveau performances, statistiquement il y a moyen que tu perdes plus de temps au niveau de tes tests pour voir s'il faut recalculer ou pas la norme.

Moi j'laisserais plutôt soin à l'utilisateur de précalculer la norme de son côté plutôt que de l'imposer à tout le monde.

Puis j'ai pas le souvenir de cas précis en géométrie où on utilise beaucoup de fois la même norme...
On calcule souvent des normes, mais à chaque fois sur des données différentes et ceci isolément.

[yan]

@Mongaulois :

Sur cet exemple précis, le coup de la norme mise en cache c'est pas du tout adapté, parce que du coup ça fait une optimisation prématurée et contre productive en plus.

Niveau mémoire, on se trimbale beaucoup de choses pour rien. Niveau performances, statistiquement il y a moyen que tu perdes plus de temps au niveau de tes tests pour voir s'il faut recalculer ou pas la norme.

Moi j'laisserais plutôt soin à l'utilisateur de précalculer la norme de son côté plutôt que de l'imposer à tout le monde.

Puis j'ai pas le souvenir de cas précis en géométrie où on utilise beaucoup de fois la même norme...
On calcule souvent des normes, mais à chaque fois sur des données différentes et ceci isolément.

Ce n'est que pour faire un exemples

[screetch]

et pourquoi immutable ne serait pas vraiment immutable ?

Code :

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

1
2
3
4
5
6
7
class Point
{
public:
  const double x;
  const double y;
  Point(double x = 0, double y = 0) : x(x), y(y) { }
};

au lieu de coltiner des const partout. autant les mette la ou ils sont.

[Médinoc]

Peut-être parce que là, la classe n'est pas assignable non-plus, ce qui n'est pas forcément l'effet désiré...

[HanLee]

Peut-être parce que là, la classe n'est pas assignable non-plus, ce qui n'est pas forcément l'effet désiré...

Si elle est assignable, alors elle n'est plus immuable.
L'important c'est qu'elle soit copiable.

[Médinoc]

J'en suis moins sûr que toi: Prends le type DateTime en .Net (ou pire, la version Java qui est un type référence). Sur une variable de ce type, tu ne peux faire aucune modification à part le remplacer complètement par un autre DateTime.

DateTime reste alors un type immuable, mais assignable.

[koala01]

Je rejoins l'avis de médinoc sur ce point:

Un objet immuable est simplement un objet pour lequel il n'existe aucune méthode qui permette de modifier la valeur d'un de ses membres.

Par contre, un objet assignable permet de fournir de nouvelles valeurs dans leur ensemble à une variable du type correspondant.

Ce pourrait être strictement identique au cas

Code :

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

1
2
3
4
 
int i = 2; // création
i *= 5; // mutation (interdit s'il s'agissait d'un objet immuable)
int j = i // assignation

[screetch]

ce n est pas parce qu il y a un cas ou ca ne marche pas que ca ne marche jamais.

[HanLee]

J'en suis moins sûr que toi: Prends le type DateTime en .Net (ou pire, la version Java qui est un type référence). Sur une variable de ce type, tu ne peux faire aucune modification à part le remplacer complètement par un autre DateTime.

DateTime reste alors un type immuable, mais assignable.

Un objet immuable est simplement un objet pour lequel il n'existe aucune méthode qui permette de modifier la valeur d'un de ses membres.

Je suis pas d'accord avec votre définition d'immutabilité.

L'immutabilité ou immuabilité, c'est comme en maths, un objet a une valeur fixe une fois pour toutes.

Mais assigner une valeur, à un objet, même si l'on remplace tout, c'est quand même modifier un objet.

C'est donc un effet de bord, on perd alors presque tout avantage de l'immuabilité vis-à-vis de la correction d'un programme, au niveau transparence référentielle et tout ça.

(Le rebinding d'une variable ne compte pas comme un effet de bord par contre).

[Médinoc]

Pour moi, l'affectation d'un DateTime "valeur" (.Net), c'est la même chose que le rebinding d'un DateTime "référence" (Java).

[HanLee]

Pour moi, l'affectation d'un DateTime "valeur" (.Net), c'est la même chose que le rebinding d'un DateTime "référence" (Java).

Je parlais plus du rebinding au sens OCaml, ou le scoping du C++, le rebinding du Java représentant juste une affectation de pointeurs pour moi.

Code C++ :

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

1
2
3
4
5
6
7
8
int i = 3;
int j = 5;
 
{
    double i = ::i * ::j;
 
    return i;
}

Code OCaml :

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

1
2
3
4
 
let i = 3 and j = 5 in
   let i = float_of_int (i * j) in
      i

A chaque fois qu'on rebind, on s'enfonce dans un scope.
En plus, on peut changer le type.

Ce n'est pas une affectation, on définit une nouvelle variable qui porte le même nom.

[koala01]

Je suis pas d'accord avec votre définition d'immutabilité.

L'immutabilité ou immuabilité, c'est comme en maths, un objet a une valeur fixe une fois pour toutes.

Mais assigner une valeur, à un objet, même si l'on remplace tout, c'est quand même modifier un objet.

(...)

Il ne faut pas confondre l'instance d'un objet et la variable qui te permet d'y accéder...

Un objet immuable est, simplement un objet pour lequel on ne dispose pas de mutateurs (méthode permettant de modifier les valeurs intrinsèques), mais rien n'empêche de faire de manière à ce que la variable qui référence un objet puisse être assignée à une autre instance de cet objet

C'est d'ailleurs ce qui se fait dans beaucoup de langages: quand tu modifie une chaine en java - par exemple - tu crées en réalité une nouvelle chaine que tu assigne à la variable qui la représente (qui permet d'y accéder)...

[HanLee]

Il ne faut pas confondre l'instance d'un objet et la variable qui te permet d'y accéder...

Un objet immuable est, simplement un objet pour lequel on ne dispose pas de mutateurs (méthode permettant de modifier les valeurs intrinsèques), mais rien n'empêche de faire de manière à ce que la variable qui référence un objet puisse être assignée à une autre instance de cet objet

C'est d'ailleurs ce qui se fait dans beaucoup de langages: quand tu modifie une chaine en java - par exemple - tu crées en réalité une nouvelle chaine que tu assigne à la variable qui la représente (qui permet d'y accéder)...

Mais je ne confonds pas...
Je l'ai signalé qu'en Java a = b, c'est faire un effet de bord sur les références, et non les objets.

Il n'empêche qu'en C++, a = b c'est un effet de bord et modifie l'objet pour de vrai.

Mais je vois pas pourquoi tu ramènes toujours la notion d'immuabilité à la POO , c'est quelque chose d'orthogonal à la POO qui n'est qu'une manière d'approcher un problème.

[Klaim]

Juste une question sur la notation des membres avec un "_" en préfixe, qui a été évoqué il y a quelques pages :
J'ai lu sur un autre forum (et il me semble dans un ou deux bouquins) que c'était réservé aux implémentations de la STL ou quelque chose de ce gout là. En fait il me semble que c'est plutot "__" qui est réservé.

Est-ce que quelqu'un ayant le standard pourrait confirmer?

Si c'est bien vrai pour "_", alors son utilisation comme préfix pour nommer les membres est potentiellement dangereuse, non?