Discussion :

[koala01]

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

[Emmanuel Deloget]

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.

[oodini]

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/

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. :-)

[Emmanuel Deloget]

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

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

Ben voilà. Tout est dit. :-)

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

[3DArchi]

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


Ben voilà. Tout est dit. :-)

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

[oodini]

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.

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.

[koala01]

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.

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

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

[oodini]

[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.

[Emmanuel Deloget]

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.