Alors, quand tu fais un "foreach (livre in bibliothèque)", alors tu sais comment l'objet stocke ses données. Si tu as une méthode "bibliotheque.traduireTout()", alors tu ne sais pas comment se débrouille la bibliothèque pour tout traduire.
Qui te dis que le bouquin que tu récupère est celui du rayonnage? C'est là qu'est l'idée selon moi. Itérer sur tous les bouquins de la bibliothèque via forEach présume que le bouquin renvoyé est celui contenu dans la bibliothèque, et cela me semble anormal puisqu'alors tu sais comment la bibliothèque stocke ses bouquins. Si ta bibliothèque classique avec des livres papiers qui prennent la poussière et toute la place devient une bibliothèque électronique, alors ok le getLivre() peut rester, mais le livre renvoyé n'est pas le livre stocké dans la bibliothèque, puisqu'il te renvoie un livre papier alors que la bibliothèque stocke (et ça, tu ne le sais pas) des livres électroniques.
Récupérer un bouquin peut donc faire sens, mais itérer sur tous les bouquins me semble insensé.
Attention: je me suis peut-être mal exprimé, mais pour moi, le "tout objet pur" est différent du "tout est objet point barre". Un "tout objet pur" est, pour moi, un programme dans lequel tout ce qui a besoin d'être objet est objet, et tout ce qui n'a pas besoin d'être objet n'est pas objet. C'est différent d'un "tout est objet".
(J'objecterai, pour finir, que permettre d'itérer sur chaque livre c'est risquer que l'utilisateur bousille les livres, car si on ne renvoie pas un nouvel objet Livre, mais une référence, ou autre assimilé, au livre dans la bibliothèque, alors l'utilisateur peut brûler ce livre sans soucis; si c'est une base de données, cela peut faire mal).
On n'est peut-être pas de la même génération (vive les jeunots de 22 ans!), mais je préfère un objet dont je ne sais rien mais à qui je peux demander "bibliotheque.toutTraduire()" plutôt qu'un objet pour lequel je dois itérer sur son contenu (donc, je dois connaitre toute la documentation de cet objet plus celle de son contenu).
En revanche, oui, si je veux m'y interfacer, il va falloir ajouter des méthodes. Mais rien n'interdit d'avoir un héritage, et de faire une BibliothequeFille qui ajoute des méthodes à Bibliothèque, qui elle peut proposer une itération en "protected" (là, c'est possible, puisqu'on reste dans la classe: l'itérateur ne "fuite" pas hors du code de la classe).
Sinon, sans un tel itérateur, c'est vrai que c'est lourd d'ajouter des méthodes... Mais quelle facilité par la suite pour faire la maintenance, puisqu'on n'a plus aucune réelle dépendance ni "fuite"
Qui te dis que le bouquin que tu récupère est celui du rayonnage? C'est là qu'est l'idée selon moi. Itérer sur tous les bouquins de la bibliothèque via forEach présume que le bouquin renvoyé est celui contenu dans la bibliothèque, et cela me semble anormal puisqu'alors tu sais comment la bibliothèque stocke ses bouquins. Si ta bibliothèque classique avec des livres papiers qui prennent la poussière et toute la place devient une bibliothèque électronique, alors ok le getLivre() peut rester, mais le livre renvoyé n'est pas le livre stocké dans la bibliothèque, puisqu'il te renvoie un livre papier alors que la bibliothèque stocke (et ça, tu ne le sais pas) des livres électroniques.
Récupérer un bouquin peut donc faire sens, mais itérer sur tous les bouquins me semble insensé.
Attention: je me suis peut-être mal exprimé, mais pour moi, le "tout objet pur" est différent du "tout est objet point barre". Un "tout objet pur" est, pour moi, un programme dans lequel tout ce qui a besoin d'être objet est objet, et tout ce qui n'a pas besoin d'être objet n'est pas objet. C'est différent d'un "tout est objet".
(J'objecterai, pour finir, que permettre d'itérer sur chaque livre c'est risquer que l'utilisateur bousille les livres, car si on ne renvoie pas un nouvel objet Livre, mais une référence, ou autre assimilé, au livre dans la bibliothèque, alors l'utilisateur peut brûler ce livre sans soucis; si c'est une base de données, cela peut faire mal).
On n'est peut-être pas de la même génération (vive les jeunots de 22 ans!), mais je préfère un objet dont je ne sais rien mais à qui je peux demander "bibliotheque.toutTraduire()" plutôt qu'un objet pour lequel je dois itérer sur son contenu (donc, je dois connaitre toute la documentation de cet objet plus celle de son contenu).
En revanche, oui, si je veux m'y interfacer, il va falloir ajouter des méthodes. Mais rien n'interdit d'avoir un héritage, et de faire une BibliothequeFille qui ajoute des méthodes à Bibliothèque, qui elle peut proposer une itération en "protected" (là, c'est possible, puisqu'on reste dans la classe: l'itérateur ne "fuite" pas hors du code de la classe).
Sinon, sans un tel itérateur, c'est vrai que c'est lourd d'ajouter des méthodes... Mais quelle facilité par la suite pour faire la maintenance, puisqu'on n'a plus aucune réelle dépendance ni "fuite"