Donc en fait, tu penses que le premier langage de programmation, celui dans lequel toutes les méthodes renvoient des chaînes, est plus générique que le deuxième ?
Donc, avec ton exemple, pour que grep marche il faut une méthode read_char. Si tu veux un cut ? il faut un select_fields(), etc ... en gros une méthode par programme à piper ?
C'est un argument circulaire: tu pars tu principe que pour faire quelque chose avec l'objet, il faut que tout le traitement soit contenu dans l'objet, et tu conclus qu'il faut une méthode par programme à piper.
Si tu veux faire un cut, tu n'as pas besoin d'une méthode qui te renvoie des champs. Tu as juste besoin d'une méthode read_char, comme pour grep. Par contre si tu as à ta disposition une méthode qui te donne une liste de champs, c'est encore mieux.
D'un autre côté, si tu prends toujours comme exemple des commandes qui manipulent du texte, tu n'auras jamais intéret à obtenir en entrée autre chose que du texte. Ça ne devient intéressant que dans le cas de données structurées associées à leur comportement.
chaque objet est spécifique.
Ce n'est pas vrai, tout dépend de la hiérarchie de classes utilisées. Si tu dis "je reçois en entrée n'importe quel objet qui implémente les méthodes ajouter et multiplier", tu peux faire un programme qui fait des opérations sur plein de types d'objets. Mais là on n'est pas dans une discution sur l'intéret de pouvoir piper des objets, on est dans une discution sur les mérites de la programmation objet en général.
Et même si chaque objet était spécifique, admettons que dans un script shell j'aie besoin de prendre une date et d'ajouter trois jours à cette date. Dans le bon vieux modèle Unix, je pourrais piper le résultat de "date" dans mon script, le parser, et ensuite écrire un algo qui ajoute trois jours, et qui change de mois/année quand c'est nécessaire. Dans un modèle objet, ça donnerait ça:
d = lire_une_date_en_entrée();
d2 = d+3;
À condition que la méthode Date::+ soit fournie par l'objet. C'est du code spécifique à l'objet Date, mais ça va tout à fait dans l'esprit de réutilisation de code, puisque c'est disponible pour tous les programmes qui veulent manipuler des dates.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Langages pour desktop. Évalué à 2.
Donc en fait, tu penses que le premier langage de programmation, celui dans lequel toutes les méthodes renvoient des chaînes, est plus générique que le deuxième ?
C'est un argument circulaire: tu pars tu principe que pour faire quelque chose avec l'objet, il faut que tout le traitement soit contenu dans l'objet, et tu conclus qu'il faut une méthode par programme à piper.
Si tu veux faire un cut, tu n'as pas besoin d'une méthode qui te renvoie des champs. Tu as juste besoin d'une méthode read_char, comme pour grep. Par contre si tu as à ta disposition une méthode qui te donne une liste de champs, c'est encore mieux.
D'un autre côté, si tu prends toujours comme exemple des commandes qui manipulent du texte, tu n'auras jamais intéret à obtenir en entrée autre chose que du texte. Ça ne devient intéressant que dans le cas de données structurées associées à leur comportement.
Ce n'est pas vrai, tout dépend de la hiérarchie de classes utilisées. Si tu dis "je reçois en entrée n'importe quel objet qui implémente les méthodes ajouter et multiplier", tu peux faire un programme qui fait des opérations sur plein de types d'objets. Mais là on n'est pas dans une discution sur l'intéret de pouvoir piper des objets, on est dans une discution sur les mérites de la programmation objet en général.
Et même si chaque objet était spécifique, admettons que dans un script shell j'aie besoin de prendre une date et d'ajouter trois jours à cette date. Dans le bon vieux modèle Unix, je pourrais piper le résultat de "date" dans mon script, le parser, et ensuite écrire un algo qui ajoute trois jours, et qui change de mois/année quand c'est nécessaire. Dans un modèle objet, ça donnerait ça:
d = lire_une_date_en_entrée();
d2 = d+3;
À condition que la méthode Date::+ soit fournie par l'objet. C'est du code spécifique à l'objet Date, mais ça va tout à fait dans l'esprit de réutilisation de code, puisque c'est disponible pour tous les programmes qui veulent manipuler des dates.