Dans n'importe quel modèle objet tu peut hériter des classes en question, c'est à mon humble avis nettement plus propre car une fois que tu es construis ton objet tu sais qu'il est fini, il faut pas en plus que tu lui ajoute des choses en plus pour le finir. De plus c'est un énorme effet de bord. Si tu passe cet objet en paramètre d'une méthode celle-ci peut écraser ta modification. Enfin ça n'apporte que du sucre syntaxique face à garder la méthode séparée (sachant que garder la méthode séparée permet de ne pas créer d'effet de bord).
Mon problème est que ce n'est pas moi qui instancie les-dits objets, et donc qui choisit leur classe. Donc je pouvais :
Méthode 1:
- Copier toute la machinerie d'instanciation, (et donc la mettre à jour quand Django évolue).
- Dériver de la classe de base pour faire ma propre classe de base, puis refaire toutes les classes filles que me fournit Django (des dizaines). Même remarque sur la maintenance.
- Utiliser ces nouvelles classes dans mon code, et dupliquer les classes fournies en contributions à Django qui utilisent les classes de Django, et pas les miennes forcément.
Méthode 2:
Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.
Ma méthode permet d'avoir un résultat élégant (comme si c'était intégré à Django de base), et sans écrire/dupliquer des pans entiers de Django. Je pense donc, dans la mesure où en des années de développement sur ce projet j'ai fait un tel "hack" 2 fois, qu'on se situe dans le domaine du hack intelligent (dont on se serait bien passé mais qui sauve la vie).
Mais oui j'ai fait attention de prendre des noms qui limitent la probabilité de collisions, et mon code est super bien testé (pas pour ce hack en particulier hein, de manière générale). Et je le répète c'est à utiliser en dernier recours.
Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.
Mes collègues qui font du Java à côté de moi, confrontés au même genre de problème, sont obligés de faire des trucs bien plus crades (surcharge de package, introspection pour modifier des trucs private...).
Mais surtout, je trouve que pour un usage qui devrait être quasi inexistant, on explique cela bien trop tôt. Comme si c'était une fonctionnalité de base du langage.
Ça c'est un autre problème, moi je dis juste que ce n'est pas inutile. Maintenant si je dois faire la promotion de Python, ce n'est pas dit que j'en parle en effet.
[^] # Re: Framework web
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Première beta de POCHE 1.0 disponible. Évalué à 2.
Mon problème est que ce n'est pas moi qui instancie les-dits objets, et donc qui choisit leur classe. Donc je pouvais :
Méthode 1:
- Copier toute la machinerie d'instanciation, (et donc la mettre à jour quand Django évolue).
- Dériver de la classe de base pour faire ma propre classe de base, puis refaire toutes les classes filles que me fournit Django (des dizaines). Même remarque sur la maintenance.
- Utiliser ces nouvelles classes dans mon code, et dupliquer les classes fournies en contributions à Django qui utilisent les classes de Django, et pas les miennes forcément.
Méthode 2:
Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.
Ma méthode permet d'avoir un résultat élégant (comme si c'était intégré à Django de base), et sans écrire/dupliquer des pans entiers de Django. Je pense donc, dans la mesure où en des années de développement sur ce projet j'ai fait un tel "hack" 2 fois, qu'on se situe dans le domaine du hack intelligent (dont on se serait bien passé mais qui sauve la vie).
Mais oui j'ai fait attention de prendre des noms qui limitent la probabilité de collisions, et mon code est super bien testé (pas pour ce hack en particulier hein, de manière générale). Et je le répète c'est à utiliser en dernier recours.
Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.
Mes collègues qui font du Java à côté de moi, confrontés au même genre de problème, sont obligés de faire des trucs bien plus crades (surcharge de package, introspection pour modifier des trucs private...).
Ça c'est un autre problème, moi je dis juste que ce n'est pas inutile. Maintenant si je dois faire la promotion de Python, ce n'est pas dit que j'en parle en effet.