Archi "trois tiers" - Page 3

Bah oui mais c'est pas moi qui pose la question

Je ne suis pas non plus convaincu par l'utilisation d'une exception, j'essaierai d'abord de faire tout ce qui est possible pour qu'il soit impossible de passer une "mauvaise" donnée dans les setters en utilisant des types aussi précis que possibles (du coup "impossible" veut dire "ne compile pas"). Pour le reste avec Velo, VeloData et toute la famille je n'ai pas tout compris (pourquoi deux objets différents Velo et VeloData ?) et j'ai l'impression que ça a pas mal changé depuis que tu m'as appelé sur ce topic, donc je me permets de sauter ^^

Ya eu du HS. Je fais un résumé et j'édite.

edit -> Bon, les posts qui traitent de la question qui m'intéressent vont de ./41 à ./46 (exception vs valeur de retour, je m'en fous en fait, du moins pour le moment)

Le problème à résoudre, c'est :
- comment agencer ces trois classes (Vélo, EditVélo et AfficheVélo), de manière à ce que AfficheVelo n'ait accès à des données de Vélo qu'en lecture seule, et que EditVelo puisse les éditer sans pour faire n'importe avec ?

-> La solution proposée par Kevin en ./43 est très tentante.
-> T'as dit non à ma proposition en ./41, pourquoi pas, mais pourrais-tu préciser stp ? (genre dans quel cas ça pourrait devenir dangereux)

Ça n'est pas que c'est dangereux, c'est juste que le mot-clé friend est fait pour violer volontairement l'encapsulation, c'est à dire ignorer toute notion de membre public, privé & co. Dans certains cas très particuliers comme par exemple quand tu écris des tests unitaires ça peut avoir son intérêt, mais dans le code "de production" je pense qu'il ne faut jamais l'utiliser (ou alors ça ne sert à rien de se prendre la tête, autant tout mettre en public et arrêter de se poser des questions de design).

Ici je suis tout à fait d'accord avec Kevin, je ferais moi aussi une vue immuable sur l'objet "Velo" pour les cas où tu veux permettre de le lire mais pas de le modifier. Beaucoup de langages objet proposent de faire cette vue immuable en passant par des interfaces (par exemple C# ou Java), mais le C++ propose const qui est une façon beaucoup plus concise de faire exactement la même chose (dans ce cas précis ; sinon const est un peu plus que ça), donc autant en profiter

Ok, merci beaucoup ! Et ça semble être la solution la plus simple, en plus.
Et que penses-tu de sa solution, toujouts en ./43, qui passe par un un objet dont hérite vélo, dont on passe le pointeur à EditVélo et à Affiche Vélo ?

c'est juste que le mot-clé friend est fait pour violer volontairement l'encapsulation

Tout comme mutable est fait pour violer volontairement const, et pourtant tu m'as dit qu'il avait son utilité.

autant tout mettre en public et arrêter de se poser des questions de design

En mode C-like en somme
Sauf que ce que je proposais me semblait proposer la simplicité, sans le viol de l'encapsulation, étant donné qu'il était question d'être friend avec une classe bien précise, et justement pas avec n'importe qui. C'est sur cette facette que j'aurais aimé avoir un avis autre que "ça viole l'encapsulation" (je suis au courant et c'est le but) et "c'est pas bien" (euh...).

M'enfin, bon, question propreté de design, je te fais confiance ya pas de souci.

Folco (./65) :
Et que penses-tu de sa solution, toujouts en ./43, qui passe par un un objet dont hérite vélo, dont on passe le pointeur à EditVélo et à Affiche Vélo ?

Bah c'est de celle-ci dont je parlais : tu as le choix entre passer un "const Velo&" ou faire une interface "ReadOnlyVelo" dont hérite "Velo" et qui n'expose que la partie lecture sans l'écriture. Les deux sont fonctionnellement équivalentes, techniquement const sera un poil plus efficace si ça te permet de ne pas passer tes méthodes en virtuel, mais ici j'imagine qu'on s'en fout complètement.

Tout comme mutable est fait pour violer volontairement const, et pourtant tu m'as dit qu'il avait son utilité.

C'est pour ça que je dis "dans ce cas précis" dans ./64. Le mot-clé const fait beaucoup de choses en C++ (peut-être trop), et je trouve qu'il y a des cas très précis où ça peut être intéressant d'utiliser mutable. Tout comme il y a des cas très précis où ça peut être intéressant d'utiliser friend, sauf qu'à mon avis ces cas-là se limitent essentiellement à du test.

Sauf que ce que je proposais me semblait proposer la simplicité, sans le viol de l'encapsulation, étant donné qu'il était question d'être friend avec une classe bien précise, et justement pas avec n'importe qui. C'est sur cette facette que j'aurais aimé avoir un avis autre que "ça viole l'encapsulation" (je suis au courant et c'est le but) et "c'est pas bien" (euh...).

Tu me demandais mon avis (tu m'as même !call pour ça), je te le donne : je n'ai jamais vu de bonne utilisation de friend dans des cas similaires à celui que tu présentes, donc je pense que ça n'est pas une bonne solution ici. Ça ne veut pas dire que c'est universellement vrai, et si mon avis n'est pas celui que tu voulais entendre j'en suis désolé, mais ça ne le change pas pour autant ^^

Zeph (./66) :
Bah c'est de celle-ci dont je parlais : tu as le choix entre passer un "const Velo&" ou faire une interface "ReadOnlyVelo" dont hérite "Velo" et qui n'expose que la partie lecture sans l'écriture. Les deux sont fonctionnellement équivalentes, techniquement const sera un poil plus efficace si ça te permet de ne pas passer tes méthodes en virtuel, mais ici j'imagine qu'on s'en fout complètement.

Ok impec c'est super, et en plus c'est trop classe !

Zeph (./66) :
et si mon avis n'est pas celui que tu voulais entendre j'en suis désolé, mais ça ne le change pas pour autant ^^

Ok ok, mais c'est moi qui chipotais ^^ En fait je l'ai écrit hier soir pour voir, ça marche mais comme ça viole un principe, ça reste crade à mes yeux aussi ^^

À mon avis, friend et mutable sont des mots-clés "hack", à éviter partout où ils ne sont pas indispensables.