(03-08-2013, 02:13 PM)oxman a écrit : Donc je dis encore heureux qu'il puisse modifier l'objet dans la librairie puisqu'il a demandé l'objet à la librairie pour travailler dessus.
Aucun rapport avec l'encapsulation.
Oui et encore une fois, si tu lis mon code, tu verras que la bibliothèque(ou librairie) contrôle la sortie du callback. Si on renvoie un bouquin, tu peux lui avoir fait ce que tu veux, son rôle est de l'accepter, elle a pas à t'emm*rder. Si par contre tu lui renvoie pas un bouquin, tu peux faire absolument ce que tu veux au bouquin qui passe dans le callback, la bibliothèque conserve la première version du bouquin. (puisque tes modifs sont pas valides).
Citation :Si je fais val.increment() dans le callback, tout va bien.
Si je fais val.value += 1 dans le callback, tout va mal.
Donc l'intégrité de la classe de t ne dépend non pas de la classe de t, mais du callback, en dehors de t?! Pourquoi un code extérieur à la classe T aurait le droit de modifier les objets stockés dans les propriétés de T? Ces objets me semblent alors être "partagés" entre T et le code externe.
Tu as fait de .value un membre public, il faut utiliser des privates, sans quoi ton objet n'est pas pur et donc oui, tu peux faire n'importe quoi.
ah ben je viens de paraphraser oxman ..
Citation :si "rendre Iterable" c'est "partager les données"
rendre itérable c'est permettre à une entité extérieure de parcourir une collection. ça peut être en lecture seule, en modification directe (ce contre quoi nous sommes d'accord), en modification avec contrôle (ce que j'ai proposé). Note que les collections comme celles de Backbone JS sont à mi-chemin, c'est au programmeur de faire quelque chose de propre.
Citation :Point de vue sécurité, l'intégrité d'une classe passe aussi par ses données (non?). Ou alors il faut vérifier, au début de chaque méthode, que les données de la classe sont intègres. Ou encore, considérer que la classe implémentant Iterable n'a le droit de ne rien faire sur ses propres données, puisque partagées.
Dans l'exemple que je donne tu pourrais facilement faire un évènement "humidité" qui détruit un livre de temps en temps. Mais si tu décides que la bibliothèque a les pleins pouvoirs sur tes bouquin, tu devra le considérer comme un conteneur unsafe et prévoir un second conteneur de backup. ça c'est pas la doctrine objet qui décide, c'est le programmeur. Mais personnellement quand j'utilise des collections, je leur demande juste de pourvoir mettre des trucs de côté pour pouvoir les récupérer plus tard ou travailler par lots.
(03-08-2013, 03:34 PM)Xenos a écrit : Pour l'aspect sécurité, je trouve que c'est mal venu de l'ignorer au sein d'un programme, car le programme ne me semble pas être une "unité", mais un assemblage de classe. ...
Ok. le 1er code ou le 2nd? Ou les deux? ou indifféremment?
En l'occurence si tu implémentes toutes les traductions dans ta classe bibliothèque c'est le même responsable moral (mais plusieurs dev possible) qui gère cette classe, donc généralement tu fais confiance à ton propre code (en termes de sécurité, les bugs c'est autre chose, bien que avec ma solution, on gère au moins les bugs qui empêchent de renvoyer un #livre{})