créer un vector<struct>

Citation:

---

Envoyé par 3DArchi

la ma notre
On est au - 2 sur ce fil mais je suis persuadé qu'en fouillant dans ce site ou dans d'autre, la cohorte serait vite dépassée.

---

+1 :D

Citation:

---

Envoyé par oodini

Dans le programme présenté dans le post original, explique-moi quelle est la contre-indication.
La question ne porte même pas sur l'encapsulation, aucune donnée métier n'est donnée, et il n'y est pas fait question d'invariant.

---

Même dans une version simplifiée du code, il y a fort à parier que l'id est lié au label. Si ce n'est pas le cas, autant utiliser std::pair<> (qui est une structure, d'ailleurs). Si c'est le cas (par exemple, l'information peut provenir d'une base de données, auquel cas le lien entre id et label est quand même relativement fort - changer id peut n'avoir aucun sens, et changer label sans changer id peut rendre les données incohérentes avec la base, auquel cas il faudra resynchroniser.

Histoire d'être sûr de ce dont on parle : structure = classe sans méthode dont toutes les données sont publiques.

Citation:

---

Envoyé par 3DArchi

L'absence d'invariant d'un type, le cas où l'encapsulation semble effectivement moins forte, est très rare. Et qui plus est, ces types 'triviaux' ont rapidement vocation à être encapsulés dans des types plus riches.

---

http://alp.developpez.com/tutoriels/traitspolicies/

Citation:

---

Envoyé par Emmanuel Deloget

Même dans une version simplifiée du code, il y a fort à parier que l'id est lié au label. Si ce n'est pas le cas, autant utiliser std::pair<> (qui est une structure, d'ailleurs).

---

Ben voilà. Tout est dit. :-)

Citation:

---

Envoyé par oodini

http://alp.developpez.com/tutoriels/traitspolicies/

---

Ca c'est de la mauvaise foi. L'utilisation des traits n'a rien à voir avec l'encapsulation.

Citation:

---

Envoyé par oodini

Ben voilà. Tout est dit. :-)

---

Enfin, il y a une condition quand même - et crois moi, elle est pétard de forte ! :)

Citation:

---

Envoyé par oodini

http://alp.developpez.com/tutoriels/traitspolicies/


Ben voilà. Tout est dit. :-)

---

:koi:
Ben non. Rien n'est dit.

Et les classes traits et politiques ont aussi des parties privées lorsqu'elles deviennent un tantinet évoluées et qu'elles ont des 'détails' d'implémentation.

Ce qui est public ne sont pas des données ou des détails d'implémentation qui ne seraient pas encapsulées mais l'équivalent des fonctions

Citation:

---

Envoyé par Emmanuel Deloget

Ca c'est de la mauvaise foi. L'utilisation des traits n'a rien à voir avec l'encapsulation.

---

Je suis tout à fait d'accord : on n'a pas forcément besoin de parler encapsulation dès qu'on parle structures.

Citation:

---

Envoyé par 3DArchi

:koi:
Ben non. Rien n'est dit.

Et les classes traits et politiques ont aussi des parties privées lorsqu'elles deviennent un tantinet évoluées et qu'elles ont des 'détails' d'implémentation.

---

Je suis d'accord. Mais le code à l'origine de ce fil ne présente pas une structure évoluée, pour le coup.

Citation:

---

Envoyé par oodini

Je suis tout à fait d'accord : on n'a pas forcément besoin de parler encapsulation dès qu'on parle structures.

---

AMHA, ce n'est pas vraiment ce qu'Emmanuel voulait dire...

Je crois qu'il voulait surtout dire que le fait est que les trait de politique utilisent essentiellement des constantes, qui seront d'ailleurs souvent des constantes de compilation.

A partir de là, il devient relativement inutile de commencer à encapsuler les données (qui ne pourront de toutes façons pas être modifiées), et ce, d'autant plus que l'on devra y accéder de manière régulière.

Citation:

---

Je suis d'accord. Mais le code à l'origine de ce fil ne présente pas une structure évoluée, pour le coup.

---

Ah, tu trouve, toi :question:

Prends simplement la peine de réfléchir à tout ce que cette "simple" structure peut nécessiter en terme de gestion :

1. id est, classiquement, un identifiant que l'on veut unique et non ambigu : comme je l'ai indiqué, la modification de l'id fait, de facto, passer à un autre objet
2. Les tests et les recherches seront, visiblement, basées sur id, vu qu'il sera sans doute unique et non ambigu: il sera sans doute de bon ton de prévoir, au minimum, la comparaison a < b avec a et b étant des dummy
3. label semble clairement destiné à représenter une chaine de caractères: il vaut clairement mieux faire en sorte que seule Dummy soit responsable de la gestion de la mémoire qui s'y rapporte ;)

Et ce ne sont là que les points les plus importants auquels j'aie pu penser durant la compilation d'un projet au boulot ;)

Citation:

---

Envoyé par koala01

[LIST=1][*]id est, classiquement, un identifiant que l'on veut unique et non ambigu : comme je l'ai indiqué, la modification de l'id fait, de facto, passer à un autre objet

---

Tu fais une présupposition non donnée dans le post.

Pour info, en France, même le numéro INSEE se modifie.

Citation:

---

Envoyé par koala01

AMHA, ce n'est pas vraiment ce qu'Emmanuel voulait dire...

Je crois qu'il voulait surtout dire que le fait est que les trait de politique utilisent essentiellement des constantes, qui seront d'ailleurs souvent des constantes de compilation.

---

C'est surtout qu'on parle d'une technique de code, et qu'on la met en face d'un principe de conception - les deux n'ont rien à voir l'un et l'autre, donc les mixer n'a pas vraiment de sens. Il existe une raison - triviale - pour laquelle les traits sont généralement des structures et pas des classes, même si, comme l'a remarqué 3DArchi, une classe avec des méthodes privées devient vite intéressante lorsque le traits se complexifie.

Prêt pour la raison ?

Dans 99% des cas, les traits sont stateless. Sans état à protéger, il est inutile d'encapsuler quoi que ce soit. Ce sont des constantes glorifiées.