Nommer, répertorier, expliquer les paramètres possibles, je préfère le mettre dans les commentaires, comme de toute façon chaque paramètre doit s'expliquer dans les commentaires ça évite d'écrire deux fois les choses. Et je n'arrive plus à voir l'intérêt de spécifier les types en Ruby, où on préfère la philosophie du "duck typing" (si ça se comporte comme un canard et que j'ai besoin d'un truc qui se comporte comme un canard, pas besoin de lui faire faire un test adn).
Par exemple, en Java, si une méthode à besoin de travailler sur un objet qui implémente une interface IJeSaisFaireQuelqueChose pour utiliser sa méthode abstraite faireQuelqueChose, alors je vais devoir implémenter l'interface pour chaque objet passé en paramètre, voir dans certains cas faire des héritages de classes définies dans des bibliothèques externes pour pouvoir leur coller juste une bête interface.
En Ruby, si une méthode à besoin d'un objets qui réponde à la méthode faire_quelque_chose(), il suffit que mon objet répondre à cette méthode et ça roule. Si vraiment je veux faire mon paranoïaque je peux tester si l'objet répond à la méthode à la réception de l'argument et lancer une exception si ce n'est pas le cas. Ca permet de découpler beaucoup mieux les classes.
Encore mieux, si j'ai une instance d'objet à passer à ma méthode, et qu'il n'a pas la méthode faire_quelque_chose(), je peux faire un module contenant une implémentation de faire_quelque_chose() et le coller à la volée à l'instance (ou à la classe) avant de le donner à manger à la méthode en question, ce qui simplifie énormément le développement orienté comportement.
On y gagne en lisibilité (code plus concis, moins de méthodes vides juste pour implémenter des interfaces, moins de méthodes qui se contentent d'en appeller une autre du même nom pour faire varier le nombre de paramètres, moins de sous-classes définies uniquement pour donner un nouveau comportement à du code existant), en temps (pour écrire des commentaires, des tests), et en réutilisabilité (pas besoin de se taper des diagrammes d'héritages ou des API de 1000+ pages pour réutiliser des libraries bien claires et bien commentées, le code est plus facile à découpler et facotriser).
Je sais que ça fait peur, on a l'impression qu'il n'y a plus de structure, que les autres développeurs (qui sont forcément nuls, fainéants, etc.) ne sont plus obligés de suivre strictement des lignes de conduite rigides et indépassables et vont faire de la merde, forcément, mais franchement, même avec Java un développeur qui fait de la merde peut vraiment faire des trucs bien puants, bien crados. Ce n'est pas la flexibilité du langague qui fait que l'on pond de la merde ou pas, c'est la méconnaissance des bonnes pratiques et la paresse.
[^] # Re: Grandiose
Posté par Bastes . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Par exemple, en Java, si une méthode à besoin de travailler sur un objet qui implémente une interface IJeSaisFaireQuelqueChose pour utiliser sa méthode abstraite faireQuelqueChose, alors je vais devoir implémenter l'interface pour chaque objet passé en paramètre, voir dans certains cas faire des héritages de classes définies dans des bibliothèques externes pour pouvoir leur coller juste une bête interface.
En Ruby, si une méthode à besoin d'un objets qui réponde à la méthode faire_quelque_chose(), il suffit que mon objet répondre à cette méthode et ça roule. Si vraiment je veux faire mon paranoïaque je peux tester si l'objet répond à la méthode à la réception de l'argument et lancer une exception si ce n'est pas le cas. Ca permet de découpler beaucoup mieux les classes.
Encore mieux, si j'ai une instance d'objet à passer à ma méthode, et qu'il n'a pas la méthode faire_quelque_chose(), je peux faire un module contenant une implémentation de faire_quelque_chose() et le coller à la volée à l'instance (ou à la classe) avant de le donner à manger à la méthode en question, ce qui simplifie énormément le développement orienté comportement.
On y gagne en lisibilité (code plus concis, moins de méthodes vides juste pour implémenter des interfaces, moins de méthodes qui se contentent d'en appeller une autre du même nom pour faire varier le nombre de paramètres, moins de sous-classes définies uniquement pour donner un nouveau comportement à du code existant), en temps (pour écrire des commentaires, des tests), et en réutilisabilité (pas besoin de se taper des diagrammes d'héritages ou des API de 1000+ pages pour réutiliser des libraries bien claires et bien commentées, le code est plus facile à découpler et facotriser).
Je sais que ça fait peur, on a l'impression qu'il n'y a plus de structure, que les autres développeurs (qui sont forcément nuls, fainéants, etc.) ne sont plus obligés de suivre strictement des lignes de conduite rigides et indépassables et vont faire de la merde, forcément, mais franchement, même avec Java un développeur qui fait de la merde peut vraiment faire des trucs bien puants, bien crados. Ce n'est pas la flexibilité du langague qui fait que l'on pond de la merde ou pas, c'est la méconnaissance des bonnes pratiques et la paresse.