C'est tout simplement parce que tu vois tous les problèmes comme des clous à planter.
Je ne suis pas sûr d'avoir complètement compris ce que tu entendais par là, mais si tu voulais dire « une manière de parvenir à ses fins, indépendamment de la curiosité mathématique », alors non. C'est même plutôt le contraire, si tu relis bien mon commentaire. C'est intéressant dans les langages tels que le Javascript qui sont non seulement interprétés, mais où les objets sont définis et remplis à l'exécution.
Par contre, il est important de ne pas faire tout et n'importe quoi juste pour résoudre le problème, même de façon théorique (ce qui nous ramènerait aux clous à planter). En développement logiciel, je suis assez adepte du « changement de paradigme », c'est-à-dire se laisser la possibilité d'utiliser un jeu de concepts totalement exotiques s'il le faut mais À CONDITION de poser le cadre dès le départ et de ne pas en sortir a posteriori au cours d'un projet, surtout si c'est pour se sortir d'une impasse.
En particulier, il y a beaucoup de gens qui font l'amalgame « classe = objet », alors que le mot « classe » doit en fait s'entendre dans le même sens que « classification du règne animal », par exemple. En ce sens, si tu ajoutes ou retires quelque chose à une classe, alors par définition, ce n'est plus la même classe ! Et ça pose problème avec les objets déjà instanciés.
Plus précisément, si l'on modifie une classe, c'est en fait l'ontologie elle-même que l'on modifie, même si cette ontologie est maintenue grâce à des données définies à l'exécution (et qui sont en fait des méta-données). Ça reste très séduisant en soi, mais c'est pour moi du même niveau que le code auto-généré. Ça n'est à utiliser qu'à partir du moment où tous les concepts initiaux sont parfaitement clairs et que, de là, on sait parfaitement ce que l'on fait.
Et là, il me semblait justement que le message du primo-postant n'avait pas vocation à débattre de ce sujet, mais était bien confronté à un cas de figure fondamental en programmation orientée objet, d'où la réponse qui me semblait être la plus appropriée.
[^] # Re: Prendre le problème à l'envers
Posté par Obsidian . En réponse au message Ajouter des méthodes à une instance de classe, après sa création. Évalué à 4.
Salut,
Je ne suis pas sûr d'avoir complètement compris ce que tu entendais par là, mais si tu voulais dire « une manière de parvenir à ses fins, indépendamment de la curiosité mathématique », alors non. C'est même plutôt le contraire, si tu relis bien mon commentaire. C'est intéressant dans les langages tels que le Javascript qui sont non seulement interprétés, mais où les objets sont définis et remplis à l'exécution.
Par contre, il est important de ne pas faire tout et n'importe quoi juste pour résoudre le problème, même de façon théorique (ce qui nous ramènerait aux clous à planter). En développement logiciel, je suis assez adepte du « changement de paradigme », c'est-à-dire se laisser la possibilité d'utiliser un jeu de concepts totalement exotiques s'il le faut mais À CONDITION de poser le cadre dès le départ et de ne pas en sortir a posteriori au cours d'un projet, surtout si c'est pour se sortir d'une impasse.
En particulier, il y a beaucoup de gens qui font l'amalgame « classe = objet », alors que le mot « classe » doit en fait s'entendre dans le même sens que « classification du règne animal », par exemple. En ce sens, si tu ajoutes ou retires quelque chose à une classe, alors par définition, ce n'est plus la même classe ! Et ça pose problème avec les objets déjà instanciés.
Plus précisément, si l'on modifie une classe, c'est en fait l'ontologie elle-même que l'on modifie, même si cette ontologie est maintenue grâce à des données définies à l'exécution (et qui sont en fait des méta-données). Ça reste très séduisant en soi, mais c'est pour moi du même niveau que le code auto-généré. Ça n'est à utiliser qu'à partir du moment où tous les concepts initiaux sont parfaitement clairs et que, de là, on sait parfaitement ce que l'on fait.
Et là, il me semblait justement que le message du primo-postant n'avait pas vocation à débattre de ce sujet, mais était bien confronté à un cas de figure fondamental en programmation orientée objet, d'où la réponse qui me semblait être la plus appropriée.