Compass : East Oriented
|
06-06-2015, 03:18 PM
Tout à fait d'accord, mais quand je vois ce qu'il répond, je ne dis pas qu'il ne comprends pas, je dis qu'il fait tout pour ne pas comprendre, c'est différent.
Quand tu vois déjà comment il mélange la vision qu'il a des tests unitaires, c'est pas étonnant.
06-06-2015, 03:48 PM
Alors expose la tienne
Okay, donc pour toi, cette vision est la bonne:
Citation :On ne test pas un valueObject, il n'a pas de comportement. C'est comme si tu voulais tester un int ou avoir une interface sur un int.Je suis d'accord. En revanche, ton Age n'est pas un valueobject pour moi (il implémente des méthodes comportementales, les comparaisons). Du coup, tu considères que cette méthode comportementale n'a pas à être testée? Okay. Maintenant il faudrait implémenter les comparaison positive, positive ou égale, négative, négative ou égale, égale, très supérieur à, très inférieur à,... Tu vas implémenter tout ça dans le value object, et ne jamais le tester? J'ai sorti la discussion sur instanceof dans un autre sujet, pour pas tout mixer et ruiner le forum 
06-06-2015, 10:57 PM
Tu test un int ? Un int ou tu peux faire int > int à un comportement ?
06-06-2015, 11:20 PM
J'ai ressorti l'histoire des valueobject dans un autre topic, histoire de ne polluer celui d'East
08-06-2015, 09:57 PM
A propos de Argent{100,$}+Argent{200,€}=Exception, est-ce que les exceptions sont considérées comme acceptables en East?
Elles remontent vers l'appelant, et dans certains langages (je pense surtout à Java), on ne peut pas throw une exception qui n'est pas dans la signature de la méthode. D'ailleurs, de manière générale, un try/throw/catch oblige l'appelant à savoir comment la méthode appelée fonctionne (pour pouvoir catcher).
23-06-2015, 05:18 PM
Concernant tout ce que l'on a dit, mageekguy (celui qui m'a fait connaître East et qui a énormément réfléchis à la question - j'ai d'ailleurs posté sa conf ici) est venu voir le forum et m'a fait un retour que je vous partage :
14:36 <mageekguy> srm`: je pense qu'une partie des problèmes que tu rencontres vient du fait que : 14:37 <mageekguy> 1) vous réfléchissez en type (Woman, Kid, Hero, Beggar) au lieu de réfléchir en terme de role (ie quel est le role du hero ? quel est le role du kid, etc), donc en classe au lieu d'interface 14:37 <mageekguy> 2) l'intérêt de east, c'est de maximiser le niveau d'abstraction 14:38 <srm`> ok tu as entièrement raison sur le 1 14:39 <mageekguy> quel est le rôle du hero ? donner de l'argent en fonction de critères, visiblement l'âge et le sexe 14:39 <mageekguy> quel est le rôle de kid et woman ? demander de l'argent à quelqu'un qui peut en donner 14:40 <srm`> en l'occurence là oui 14:40 <mageekguy> tu as donc un rôle money\provider et un rôle money\consumer (par exemple) 14:40 <mageekguy> à partir de là, il faut qu'un money\consumer puisse répondre aux critères du money\provider 14:41 <srm`> ça oui 14:41 <srm`> mais ça répondra pas à la question "et si je veux traiter différement si c'est une femme ?" 14:41 <mageekguy> donc ça implique money\consummer::giveGenderToMoneyProvider() 14:43 <mageekguy> (ou money\consumer::genderIsAskedBy...) 14:43 <mageekguy> quand tu remplis un questionnaire de santé à la banque pour avoir ton crédit 14:43 <mageekguy> ça se passe comme ça 14:44 <mageekguy> le questionnaire est "sexe agnostique" 14:44 <mageekguy> la personne qui demande le prêt a le rôle de "demandeur" 14:45 <mageekguy> et le questionnaire lui dit "j'ai besoin de ton sexe", "j'ai besoin de ton âge", "j'ai besoin de la liste de tes interventions chirurgicales", etc 14:45 <mageekguy> ce n'est pas "une femme" ou "un homme" qui remplit le formulaire 14:45 <mageekguy> c'est "le demandeur" qui déclare être un homme ou une femme 14:47 <mageekguy> ton women|kid, c'est money\consumer 14:48 <mageekguy> et la façon dont le hero va qualifier le money\consumer dépendera des informations que le money\consumer va lui communiquer suivant le protocole défini entre eux 14:48 <mageekguy> via leurs interfaces respectives Qu'en pensez-vous ? Ca vous parle plus ? |
|
|
