05-09-2015, 11:03 PM
Décidément, tu essayes de me pousser dans mes retranchements 
Voilà un autre code qui, je l'espère répondra à tes questions : https://gist.github.com/Max-koder/04d8a4515cdb4173503e
- J'ai à présent 2 interfaces et une classe abstraite
- Plus de conversion à la main dans le code utilisateur
L'idée est de convertir toutes les devises en dollars lors de la récupération par 'getUniformDevise()'. Je te laisse critiquer
Je ne saisi pas la suite. La monnaie est créée par l'utilisateur (donc une valeur non définie dans le code) ? Si c'est cela, j'implémenterai une classe générique comme ma RealDevise avec une propriété $taux_de_conversion, qui serait récupérée depuis ma BDD. Ensuite une petite conversion, et on arrive facilement à voir si 2 monnaies se valent ou pas. En fait, je ne comprends vraiment pas ton problème ^^
Imaginons que tu achètes une moto. Tu lui enlèves le guidon, met un volant, l'élargit, lui rajoute une carrosserie et pose 2 roues supplémentaires. C'est toujours une moto ? Pas pour moi.
DTO Immutable : Un DTO n'est pour moi pas immutable, mais bon.
Simple conteneur de données, sans aucun check ni comportement. On lui donne une valeur, on peut la modifier, la récupérer, point.
ValueObject : Immutable, comparaison basée sur la/les attributs et non sur l'identité.
Objet : Tout ce que permet un objet (statique, dynamique, getters, setters, .............).
Citation :Je ne suis effectivement pas convaincu car, mis à part le fait que j'aurai utilisé une interface Temperature et non une classe abstraite, il faut faire la conversion à la main dans le code utilisateur.
De plus, puisque tu parles de monnaie, comment vas-tu faire pour implémenter un système où la monnaie est une donnée? Par exemple, si les joueurs peuvent créer leur propre monnaie dans le jeu, tu ne peux pas avoir 1 classe par monnaie: il te faudra forcément une classe générique à toutes les monnaies. Du coup, si j'ai {100;€} et {130;$}, comment savoir si cela représente la même somme d'argent?
Voilà un autre code qui, je l'espère répondra à tes questions : https://gist.github.com/Max-koder/04d8a4515cdb4173503e
- J'ai à présent 2 interfaces et une classe abstraite
- Plus de conversion à la main dans le code utilisateur
L'idée est de convertir toutes les devises en dollars lors de la récupération par 'getUniformDevise()'. Je te laisse critiquer
Je ne saisi pas la suite. La monnaie est créée par l'utilisateur (donc une valeur non définie dans le code) ? Si c'est cela, j'implémenterai une classe générique comme ma RealDevise avec une propriété $taux_de_conversion, qui serait récupérée depuis ma BDD. Ensuite une petite conversion, et on arrive facilement à voir si 2 monnaies se valent ou pas. En fait, je ne comprends vraiment pas ton problème ^^
Citation :C'est vrai. Donc un ValueObject peut évoluer en Object normal?Je n'ai pas dit ça. Tu as simplement besoin d'un objet, c'est tout. Si tu prends un Value Object très simple (comme ici : https://gist.github.com/Max-koder/224c1488db1e05c54755 ), tu lui ajoute des setters et d'autres méthodes, ce n'est plus un VO, mais un objet classique.
Imaginons que tu achètes une moto. Tu lui enlèves le guidon, met un volant, l'élargit, lui rajoute une carrosserie et pose 2 roues supplémentaires. C'est toujours une moto ? Pas pour moi.
Citation :Mais "toCelsius" et "toFahrenheit" (voire "toKelvin", "toReaumur", "toLeiden"...), ce ne sont pas des comportements?Si. Mais je n'ai jamais dit qu'un VO ne devait pas possèder de comportement, contrairement aux DTO d'ailleurs.
Citation :quelle différence entre DTO Immutable, ValueObject, et Object?Ca sent la conclusion ça ^^
DTO Immutable : Un DTO n'est pour moi pas immutable, mais bon.
Simple conteneur de données, sans aucun check ni comportement. On lui donne une valeur, on peut la modifier, la récupérer, point.
ValueObject : Immutable, comparaison basée sur la/les attributs et non sur l'identité.
Objet : Tout ce que permet un objet (statique, dynamique, getters, setters, .............).