Re: Le titre est trop long

Cela fait toujours plus que ton exemple java, mais cela me permet d'utiliser cette méthode sur tout type pouvant s'itérer, que ce soit un fichier, un tableau excel, une main (pour lire les ligne de la main… bon ok ;) ), là où dans ton exemple il faudrait sous classer file et/ou recoder un tas de trucs

J'aime pas cette philosophie du « Un anneau pour les gouverner tous ».
Parce qu'après, on essaie de tout faire rentrer pour pouvoir utiliser cette méthode, quitte à dévier un peu de ce qu'on aurait du réellement faire. Par exemple ici, y'a fort à parier qu'un gus ira inventer des open/close dummy rien que pour se faire plaisir d'utiliser cette méthode…
Et à l'inverse, on va plâtrer méchamment cette méthode dans tous les coins pour traiter toutes les petites subtilités à la con (« Ah oui mais mon fichier est déjà ouvert et/ou je ne veux pas le fermer », etc), en gardant une compatibilité afin de ne pas casser les 99 autres % de l'application qui utilisent cette méthode:

def readToArray anInput
 arr = []
 begin
 if isinstanceof(anInput, file) and file.isOpen():
 open = false
 else:
 open = true
 anInput.open
 anInput.each { |elm| arr << elm }
 ensure
 if open:
 anInput.close
 end
end

(ne rigolez pas, j'ai déjà vu des trucs comme ça, y compris dans des libs python ultra-utilisées…)

Non, pour moi, un fichier ne doit pas être lu par la même méthode qu'un main ou qu'une table excel. Que le comportement derrière soit mutualisé si possible via du polymorphisme, c'est autre chose.
Ça a l'énorme avantage de pouvoir isoler les choses facilement si (comprendre « quand ») une évolution future arrivera.

On s'en fout, ton test U doit être sur que pour un type itérant, la méthode te renvoi un tableau contenant chaque élément de ce type, au dev qui développera ce type de faire les tests U qui confirme que son objet sait ouvrir/itérer/fermer

Sauf que sans aller voir ta méthode, et même avec toute la meilleure volonté du monde, sans aller voir dans ton code, je n'aurais AUCUN moyen de savoir que je dois répondre à open, each et close !
Sans parler que plus je vais aller vers les couches hautes, plus les tests que tu demandes seront impossibles à vérifier, vu la quantité effroyable de comportements qu'un simple objet devra respecter !