Il y a un raccourci qui a été fait dans - rajouter une méthode à un objet - :
Dans du code propre, on inclut des méthodes dans un module, et on crée une méthode qui vient encapsuler l'inclusion de ce module.
On se retrouve donc avec un ensemble de méthode qui véhiculent un concept donné, que l'on applique à un objet. Cela se retrouve dans Rails avec tous les act_as_tree, has_attached_file et autres, qui viennent tout encapsuler.
Moralité, d'un point de vue du développeur qui utilise une telle librairie, la seule chose que j'ai à connaître c'est c'est la méthode pour intégrer les fonctionnalités et son prototype. La personne qui développe l'API peut ainsi modifier autant qu'elle le souhaite son code, faire absolument tout ce qu'elle veut tant qu'elle respecte le *contrat* passé avec le développeur, c'est à dire la méthode d'inclusion. Finalement c'est indépendant de toute forme d'implémentation, donc beaucoup plus encapsulé.
Je vois mal comment je pourrais arriver à une telle souplesse avec de l'héritage, avec un *contrat* si simple avec le programmeur. Cela ne me parait pas du tout être en contradiction avec le paradigme de la POO, c'est juste une différence fondamentale entre les langages dynamiques et statiques. Enfin, je comprend tout à fait ta résistance face à ce concept, je travaillais exclusivement en C++ il y a quelques années et ces concepts me faisait hérisser les poils. Et puis j'ai testé, la clarté du code qui en résulte m'a surpris au plus haut point. L'écriture de DSL d'ailleurs serait impossible sans une telle possibilité.
La notion de rajouter une méthode à un objet à la volée est à prendre aussi avec des pincettes dans le sens où généralement il est peu courant de le faire hors de la phase de création d'une instance. Parcourir les différentes implémentations des design patterns en Ruby est surprenant de synthétisme et lisibilité ( une fois les concepts de base maitrisés ).
[^] # Re: Python vs Ruby
Posté par jhc_ . En réponse au journal Choisir un framework web.... Évalué à 2.
Dans du code propre, on inclut des méthodes dans un module, et on crée une méthode qui vient encapsuler l'inclusion de ce module.
On se retrouve donc avec un ensemble de méthode qui véhiculent un concept donné, que l'on applique à un objet. Cela se retrouve dans Rails avec tous les act_as_tree, has_attached_file et autres, qui viennent tout encapsuler.
Moralité, d'un point de vue du développeur qui utilise une telle librairie, la seule chose que j'ai à connaître c'est c'est la méthode pour intégrer les fonctionnalités et son prototype. La personne qui développe l'API peut ainsi modifier autant qu'elle le souhaite son code, faire absolument tout ce qu'elle veut tant qu'elle respecte le *contrat* passé avec le développeur, c'est à dire la méthode d'inclusion. Finalement c'est indépendant de toute forme d'implémentation, donc beaucoup plus encapsulé.
Je vois mal comment je pourrais arriver à une telle souplesse avec de l'héritage, avec un *contrat* si simple avec le programmeur. Cela ne me parait pas du tout être en contradiction avec le paradigme de la POO, c'est juste une différence fondamentale entre les langages dynamiques et statiques. Enfin, je comprend tout à fait ta résistance face à ce concept, je travaillais exclusivement en C++ il y a quelques années et ces concepts me faisait hérisser les poils. Et puis j'ai testé, la clarté du code qui en résulte m'a surpris au plus haut point. L'écriture de DSL d'ailleurs serait impossible sans une telle possibilité.
La notion de rajouter une méthode à un objet à la volée est à prendre aussi avec des pincettes dans le sens où généralement il est peu courant de le faire hors de la phase de création d'une instance. Parcourir les différentes implémentations des design patterns en Ruby est surprenant de synthétisme et lisibilité ( une fois les concepts de base maitrisés ).