j'apprends php (3)

[Olivier Masson]

Bonjour,

Je souhaitais modifier un projet qui ne m'appartient pas.
Mais dès le départ, quelque chose dont la logique m'échappe. Je veux
créer une classe dérivée. Or, c'est cette classe dérivée qu'il faudra
/instancier/.

Mais cette classe que je veux dériver l'a déjà été par d'autres pour
ajouter des fonctionnalités.
Chacun donne son petit nom et on se retrouve avec autant de nomq qu'il
existe de fonctionnalités supplémentaires.
class diet extends original
class crystal extends original
class sans-cafeine extends original

Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?

Merci.

[Jean-Francois Ortolo]

Post by Olivier Masson
Bonjour,
Je souhaitais modifier un projet qui ne m'appartient pas.
Mais dès le départ, quelque chose dont la logique m'échappe. Je veux
créer une classe dérivée. Or, c'est cette classe dérivée qu'il faudra
/instancier/.
Mais cette classe que je veux dériver l'a déjà été par d'autres pour
ajouter des fonctionnalités.
Chacun donne son petit nom et on se retrouve avec autant de nomq qu'il
existe de fonctionnalités supplémentaires.
class diet extends original
class crystal extends original
class sans-cafeine extends original
Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?
Merci.

Bonjour Monsieur

En C++, c'est l'héritage mutiple qui permet celà, je crois...

En fait, je confond un peu la notion d'interface en Java, avec la
notion d'héritage ( je n'ai plus lu un bouqin sur javase depuis très
longtemps, même chose en C++, et je ne sais même pas si le concept
d'interface existe en C++, et je ne suis pas très ferré en poo ).

Nonobstant la possibilité de simplement recopier le code des
différentes classes en question, n'y aurait-il pas risque, en cas
d'héritage multiple à partir de plusieurs classes dérivées d'une classe,
de collision entre objets instanciés de la classe résultante, qui
seraient le résultat de chacune des classes héritées, donc risque de
collision si les fonctionnalités se recouvrent, ou si ces classes
héritées, utilisent de manière différente des méthodes ou des variables
héritées de la classe racine ?

En d'autres termes, est-il envisageable en poo, de concevoir un
héritage multiple à partir de plusieurs classes, si deux au moins des
classes ancêtres, héritent d'une classe unique ?

Bien à vous.

Amicalement.

Jean-François Ortolo

[Bruno Desthuilliers]

Post by Olivier Masson
Bonjour,
Je souhaitais modifier un projet qui ne m'appartient pas.
Mais dès le départ, quelque chose dont la logique m'échappe. Je veux
créer une classe dérivée. Or, c'est cette classe dérivée qu'il faudra
/instancier/.
Mais cette classe que je veux dériver l'a déjà été par d'autres pour
ajouter des fonctionnalités.
Chacun donne son petit nom et on se retrouve avec autant de nomq qu'il
existe de fonctionnalités supplémentaires.

Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Post by Olivier Masson
class diet extends original
class crystal extends original
class sans-cafeine extends original
Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?

Cf ci-dessus. Encore une fois, sans connaître le contexte, ça relève un
peu de la boule de cristal, mais je pense qu'un refactoring basé sur les
deux patterns ci-dessus pourrait être un bon point de départ.

Mes deux centimes...

[Olivier Masson]

Post by Bruno Desthuilliers
Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.
Mais, plus généralement (la classe que j'utilise est très simple : il
s'agit de fpdf dont j'ai parlé dans un autre fil), si on souhaite
modifier une classe très connue, utilisée, mise à jour régulièrement,
c'est uniquement par héritage qu'on peut ajouter des fonctions non ?

[Bruno Desthuilliers]

Post by Olivier Masson

Post by Bruno Desthuilliers
Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.

C'est relativement documenté sur le net.

Le pattern stratégie consiste à déléguer une partie déterminée du
comportement à un autre objet (ou à une fonction de rappel pour ce que
ça vaut), généralement spécifié(e) à l'instanciation. Ca permet de
"plugger" des comportements différents sans devoir toucher à la classe
de base ou créer une nouvelle sous-classe.

Le pattern décorateur consiste à ajouter/adapter les fonctionnalités
d'un objet en le décorant dans un autre objet (compatible du point de
vue de l'API of course), le quel délèguera une partie du travail à
l'objet d'origine.

Dans les deux cas, on se base sur un principe de composition /
délégation, dont l'héritage n'est finalement qu'une forme statique et
fortement couplée. L'avantage par rapport à l'héritage réside dans le
découplage et l'aspect dynamique.

Ces deux techniques, utilisées séparément ou conjointement permettent de
varier/adapter les comportements sans avoir de problème d'explosion
combinatoire des sous-classes - le problème que tu rencontres actuellement.

Post by Olivier Masson
Mais, plus généralement (la classe que j'utilise est très simple : il
s'agit de fpdf dont j'ai parlé dans un autre fil), si on souhaite
modifier une classe très connue, utilisée, mise à jour régulièrement,
c'est uniquement par héritage qu'on peut ajouter des fonctions non ?

Encore une fois : l'héritage (dans le sens "héritage d'implémentation")
est extrêment survalorisé et surestimé dans la majorité de la
littérature introductive à l'OO. En pratique, dans un langage à typage
dynamique (ou à inférence de type), l'héritage d'implémentation n'est
qu'une forme statique et très fortement couplée de composition / délégation.

Si tu veux juste AJOUTER des fonctionnalités, le pattern décorateur est
une autre solution, dont la raison d'être est précisément d'éviter
l'explosion combinatoire des sous-classes - puisqu'un décorateur
acceptera aussi bien de décorer l'objet "de base" qu'un *autre*
décorateur, ce qui permet de "composer" dynamiquement un objet de base
et X décorateurs.

Pour reprendre ton example, "diet", "crystal" et "sans-cafeine" seraient
des décorateurs pour "original", et pour avoir la combinaison des trois,
tu les compose juste dans l'ordre qui te convient, ie:

$bidule = new DecorateurDiet(
new DecorateurCrystal(
new DecorateurSansCafeine(
new Original()
)
)
);


HTH

[Olivier Masson]

Post by Bruno Desthuilliers

Post by Olivier Masson

Post by Bruno Desthuilliers
Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.

C'est relativement documenté sur le net.
Le pattern stratégie consiste à déléguer une partie déterminée du
comportement à un autre objet (ou à une fonction de rappel pour ce que
ça vaut), généralement spécifié(e) à l'instanciation. Ca permet de
"plugger" des comportements différents sans devoir toucher à la classe
de base ou créer une nouvelle sous-classe.
Le pattern décorateur consiste à ajouter/adapter les fonctionnalités
d'un objet en le décorant dans un autre objet (compatible du point de
vue de l'API of course), le quel délèguera une partie du travail à
l'objet d'origine.

Très intéressant, même si j'ai dû couper la musique pour me concentrer :)
Mais j'ai une question plus générale à te poser : tu sembles (j'ai
appris à prendre du recul et à tout relativiser) avoir de solides
connaissances en développement.

Par contre, le moindre micro-projet parait être une montagne de
complexité avec ton savoir-faire (car il faut, entre autres, tout
concevoir à la (ta ?) perfection et avec une vision sur le long terme).
Certes, peut-être pas pour toi qui a l'habitude, mais pour le
commun-des-mortels-qui-développent-déjà-un-tout-petitpetit-peu que je
suis, c'est plutôt abscons et très théorique.

Ce qui m'a séduit il y a peu, parce que j'essaie de l'appliquer depuis
fort longtemps, c'est le concept de méthode agile - oui, cela devient
très "tendance" et donc probablement surestimé -.

Or, j'ai *l'impression* que tu en es à l'opposée. Est-ce que je me
trompe ? Penses-tu que tes méthodes soient adaptées à un projet de
taille minuscule, modeste, moyenne ?
L'argument "tu ne sais pas ce que ton projet sera demain", je le
comprends, mais il est parfois beaucoup plus productif (et rentable,
efficace...) de faire un projet à sa juste mesure puis, si besoin est,
repartir en partie ou en totalité à zéro, avec une méthode adaptée à la
nouvelle importance du projet.

Ça me fait un peu penser à MVC que j'avais, il y a encore peu de temps,
honte de ne pas utiliser.
Finalement, maintenant que je fais parfois mon propre MVC, je suis tout
à fait convaincu que cette structure n'a rien d'idéale (et il m'arrive
donc de l'utiliser uniquement sur des parties de site).

Qu'en penses-tu ?
Tout ceci est important pour moi car on ne lit que rarement sur le net
des propos nuancés, qui prennent en compte des contextes très différents
(le meilleur CMS c'est X, le meilleur framework JS c'est Y, etc.)

[Bruno Desthuilliers]

Post by Olivier Masson

Post by Bruno Desthuilliers

Post by Olivier Masson

Post by Bruno Desthuilliers
Problème de conception assez courant hélas consistant à abuser de
l'héritage au lieu de réfléchir. Après, sans connaître le contexte, pas
moyen de dire quelle serait la bonne solution, mais à vue de nez on
pourrait penser aux patterns "décorateur" et "stratégie".

Bien entendu, j'ignore ce que sont ces patterns.

C'est relativement documenté sur le net.
Le pattern stratégie consiste à déléguer une partie déterminée du
comportement à un autre objet (ou à une fonction de rappel pour ce que
ça vaut), généralement spécifié(e) à l'instanciation. Ca permet de
"plugger" des comportements différents sans devoir toucher à la classe
de base ou créer une nouvelle sous-classe.
Le pattern décorateur consiste à ajouter/adapter les fonctionnalités
d'un objet en le décorant dans un autre objet (compatible du point de
vue de l'API of course), le quel délèguera une partie du travail à
l'objet d'origine.

Très intéressant, même si j'ai dû couper la musique pour me concentrer :)
Mais j'ai une question plus générale à te poser : tu sembles (j'ai
appris à prendre du recul et à tout relativiser) avoir de solides
connaissances en développement.

Tu a bien raison de relativiser.

Post by Olivier Masson
Par contre, le moindre micro-projet parait être une montagne de
complexité avec ton savoir-faire (car il faut, entre autres, tout
concevoir à la (ta ?) perfection et avec une vision sur le long terme).

Non. Contrairement à ce que tu sembles croire, je suis pour les
solutions simples (disons "aussi simples que possibles"), et ça fait
bien longtemps que j'ai cessé de croire qu'on pouvait "tout concevoir à
la perfection". Quand à la "vision sur le long terme", la mienne se
restreint généralement à essayer de finir le projet avec pas trop de
retard et pas trop de conneries dedans.

Post by Olivier Masson
Certes, peut-être pas pour toi qui a l'habitude,

Effectivement, l'expérience aide à éviter dès le départ certaines
vieilles erreurs. Ca n'empêche pas d'en faire de nouvelles, hélas :-/

Post by Olivier Masson
mais pour le
commun-des-mortels-qui-développent-déjà-un-tout-petitpetit-peu que je
suis, c'est plutôt abscons et très théorique.

Crois moi, quand tu a été confronté plusieurs fois au même problème, ça
n'a plus rien de théorique.

Post by Olivier Masson
Ce qui m'a séduit il y a peu, parce que j'essaie de l'appliquer depuis
fort longtemps, c'est le concept de méthode agile - oui, cela devient
très "tendance" et donc probablement surestimé -.

Possiblement, mais il y a quelques considérations pleines de bon sens là
dedans, spécialement pour des petits projets avec des petites équipes,
des deadlines serrées, et des spécifications "flottantes" - donc une
bonne partie du développement web.

Par contre, et on le soulignera jamais assez, ces méthodologies ne
peuvent fonctionner correctement que pour des équipes composées
majoritairement de personnes expérimentées.

Post by Olivier Masson
Or, j'ai *l'impression* que tu en es à l'opposée. Est-ce que je me
trompe ?

Oui.

Le fait d'utiliser par exemple un pattern décorateur (pas forcément de
façon "canonique" d'ailleurs - ce sont des motifs de *conception*, pas
d'implémentation) plutôt que l'héritage dans un cas comme celui que tu
soulèves ne relèves pas du BigDesignUpFront - c'est le genre de choix
qui s'impose d'eux-mêmes pendant le développement quand on connait le
problème et la solution. C'est à peu près aussi naturel que de
factoriser le code commun dans une fonction (ou méthode) quand on voit
qu'on est en train de se répéter et que cette répétition n'est pas
accidentelle.

Post by Olivier Masson
Penses-tu que tes méthodes soient adaptées à un projet de
taille minuscule, modeste, moyenne ?

La plupart des projets sur lesquels je bosse sont de taille suffisament
modeste pour qu'un seul dév y soit affecté. Sur les plus gros, on est
deux dév... Quant à mes méthodes, au final, ça se résume à ça:

http://www.cafenware.com/la-rache/index.php?z=2

Post by Olivier Masson
L'argument "tu ne sais pas ce que ton projet sera demain", je le
comprends,

En ce qui me concerne, c'est un excellent argument pour ne PAS partir
dans des trucs inutiles. Par contre, ça n'implique pas de laisser son
cerveau au vestiaire. Ce n'est pas parce que je ne sais pas comment le
projet va évoluer que je ne vais pas essayer d'avoir ajourd'hui une
solution raisonnablement propre.

Post by Olivier Masson
mais il est parfois beaucoup plus productif (et rentable,
efficace...) de faire un projet à sa juste mesure puis, si besoin est,
repartir en partie ou en totalité à zéro, avec une méthode adaptée à la
nouvelle importance du projet.

Oui et non. Je n'essaie pas de faire plus que ce qu'il y a dans les
specs, justement parce que je n'ai aucune idée de comment le projet va
être amené à évoluer (et qu'à chaque fois que j'ai essayer de deviner,
je me suis planté). Par contre, par expérience, garder son code
raisonnablement propre et factorisé, avoir un schéma de données
normalisé et correspondant au problème à résoudre, etc etc, ça rend
service quand les premières demandes d'évolutions arrivent.

Post by Olivier Masson
Ça me fait un peu penser à MVC que j'avais, il y a encore peu de temps,
honte de ne pas utiliser.
Finalement, maintenant que je fais parfois mon propre MVC, je suis tout
à fait convaincu que cette structure n'a rien d'idéale (et il m'arrive
donc de l'utiliser uniquement sur des parties de site).

Je vais (encore...) faire figure de puriste pédant, mais parler de MVC
pour du dev web est assez inapproprié - l'architecture MVC (la vraie)
concerne les GUI traditionnels, et réponds à des besoins (et à un modèle
d'exécution) très différents.

Maintenant, l'approche consistant à séparer autant que possible les
trois composants que sont #1 la logique applicative, #2 la gestion des
actions de l'utilisateur et #3 la logique de présentation, est
globalement une approche plutôt saine quelque soit le contexte.

Note cependant que rien de tout ça ne requiert de faire de la POO ni de
partir dans des délires d'"architecte astronaute". On peut appliquer
cette approche *très* simplement en bon vieux PHP procédural à la papa.
On n'a pas attendu la POO pour faire du code modulaire, tu sais ?

Post by Olivier Masson
Qu'en penses-tu ?

De quoi ?-)

Post by Olivier Masson
Tout ceci est important pour moi car on ne lit que rarement sur le net
des propos nuancés,

Au risque de te décevoir, je ne suis pas spécialement connu pour mon
sens de la nuance, loin s'en faut !-)

[Olivier Masson]

Post by Bruno Desthuilliers
Possiblement, mais il y a quelques considérations pleines de bon sens là
dedans, spécialement pour des petits projets avec des petites équipes,
des deadlines serrées, et des spécifications "flottantes" - donc une
bonne partie du développement web.
Par contre, et on le soulignera jamais assez, ces méthodologies ne
peuvent fonctionner correctement que pour des équipes composées
majoritairement de personnes expérimentées.

Pas vraiment d'accord.
Forcément, des personnes expérimentées feront du meilleur travail.
Forcément, quand le simple bon sens est décrit dans une méthode, qu'il
faut appliquer cette méthode, qu'elle repose sur des critères précis (et
à trop en faire s'éloigne de la simplicité qu'elle prone), il faut des
gens compétents.
Mais, contrairement à ce que tu dis, je pense que les méthodes agiles -
encore une fois, sans rentrer dans des descriptifs complexes mais en
gardant juste les bons principes - permettent à des équipes peu
expérimentées de s'en sortir bcp mieux.
Certes je ne fais pas d'XP mais, naturellement, j'essayais d'appliquer
beaucoup de points décrit dans l'XP, avant même que j'en aie (eusse ?)
entendu parler.

Post by Bruno Desthuilliers
La plupart des projets sur lesquels je bosse sont de taille suffisament
modeste pour qu'un seul dév y soit affecté. Sur les plus gros, on est
http://www.cafenware.com/la-rache/index.php?z=2

C'est amusant, mais à moins que tu ne sois purement autodidacte et que
tu n'aies jamais lu de bouquins sur le développement, tu as forcément
été influencé par des livres, des revues, des sites, des profs, etc.

Post by Bruno Desthuilliers
Maintenant, l'approche consistant à séparer autant que possible les
trois composants que sont #1 la logique applicative, #2 la gestion des
actions de l'utilisateur et #3 la logique de présentation, est
globalement une approche plutôt saine quelque soit le contexte.

Oui, lorsque l'on parle de journées de dev pour un site.
Sur un site qui utilise une poignée de ligne de code, c'est un peu
ridicule (et lent, et peu pratique, et à l'inverse du but de ce type
d'architecture).

Post by Bruno Desthuilliers
Note cependant que rien de tout ça ne requiert de faire de la POO ni de
partir dans des délires d'"architecte astronaute". On peut appliquer
cette approche *très* simplement en bon vieux PHP procédural à la papa.
On n'a pas attendu la POO pour faire du code modulaire, tu sais ?

Oui, ça, c'est bien la chose que je sais puisque je l'applique :)

Post by Bruno Desthuilliers
Au risque de te décevoir, je ne suis pas spécialement connu pour mon
sens de la nuance, loin s'en faut !-)

La nuance n'est pas vraiment une qualité partagée par beaucoup, surtout
sur le net ! Mais je le disais : j'ai appris à relativiser ;)

[Pascal]

Post by Olivier Masson
Bonjour,

Bonjour,

Post by Olivier Masson
Je souhaitais modifier un projet qui ne m'appartient pas.

Bon courage ! ;-)

Post by Olivier Masson
Mais dès le départ, quelque chose dont la logique m'échappe. Je veux
créer une classe dérivée. Or, c'est cette classe dérivée qu'il faudra
/instancier/.

Pas de problème a priori.

Post by Olivier Masson
Mais cette classe que je veux dériver l'a déjà été par d'autres pour
ajouter des fonctionnalités.
Chacun donne son petit nom et on se retrouve avec autant de nomq qu'il
existe de fonctionnalités supplémentaires.
class diet extends original
class crystal extends original
class sans-cafeine extends original

Ok, donc plusieurs classes filles héritant de la même classe parent.
Que du classique jusque-là.

Post by Olivier Masson
Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?

Ah oui, c'est là que ça coince.
Pas d'héritage multiple avec PHP, donc pas de possibilité d'écrire une
définition de classe genre :
class Total extends Diet, Crystal, Sans_cafeine {...}

La seule solution, je crois, est de redéfinir une classe héritant de la
classe de base (Original) et reprenant les propriétés et méthodes
intéressantes des classes étendues.

Il y en a d'autres nettement plus tordues que je déconseille, du type :
http://fr2.php.net/manual/fr/language.oop5.basic.php#88249

Post by Olivier Masson
Merci.

De rien.
Cordialement,
Pascal

[Bruno Desthuilliers]

(snip)

Post by Pascal
Ok, donc plusieurs classes filles héritant de la même classe parent.
Que du classique jusque-là.

Hélas oui - une erreur classique... Qui se perpétuera tant que la
littérature introductive à l'OO présentera l'héritage comme une
fonctionnalité essentielle, de préférence à travers des examples ineptes.

L'héritage, c'est comme les regexps - un super outil quand on l'utilise
à bon escient...

Post by Pascal

Post by Olivier Masson
Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?

Ah oui, c'est là que ça coince.
Pas d'héritage multiple avec PHP, donc pas de possibilité d'écrire une
class Total extends Diet, Crystal, Sans_cafeine {...}

Le problème n'est pas tant lié à l'absence d'héritage multiple qu'à
l'utilisation manifestement inappropriée de l'héritage en premier lieu.

Post by Pascal
La seule solution, je crois, est de redéfinir une classe héritant de la
classe de base (Original) et reprenant les propriétés et méthodes
intéressantes des classes étendues.

En les copiants/collant ???

Post by Pascal
http://fr2.php.net/manual/fr/language.oop5.basic.php#88249

Tordue en effet, mais ça donne au moins un point de départ pour une
implémentation d'un support générique de la composition/délégation en PHP.

[Mickael Wolff]

Post by Bruno Desthuilliers
Tordue en effet, mais ça donne au moins un point de départ pour une
implémentation d'un support générique de la composition/délégation en PHP.

Sauf que le code est faux, pas assez générique en fait. Dès qu'il y
aura des propriétés privées ans les ancetres ou les descendant, ça
pétera. J'ai essayé dans mon Framework, j'ai eu des problèmes :p

[Bruno Desthuilliers]

Post by Mickael Wolff
Sauf que le code est faux,

C'est possible en effet - honnêtement, je n'ai fait que survoler
l'exemple :-/

[Olivier Masson]

Post by Pascal
Ah oui, c'est là que ça coince.
Pas d'héritage multiple avec PHP, donc pas de possibilité d'écrire une
class Total extends Diet, Crystal, Sans_cafeine {...}

Ok, donc ça existe. Le contraire me semblait étrange.

Après, me débrouiller avec ce que j'ai, c'est simple. Mais j'aurais
voulu faire plus conventionnel pour apprendre. PHP5 ne le permettant
pas, on va faire du copier/coller.

Merci.

[Bruno Desthuilliers]

Post by Olivier Masson

Post by Pascal
Pas d'héritage multiple avec PHP

Ok, donc ça existe. Le contraire me semblait étrange.

Ca existe, certes, mais en pratique ça pose au moins autant de problèmes
que ça n'en résoud. Particulièrement dans un langage à typage dynamique,
où on n'a pas besoin de l'héritage de type pour supporter le polymorphisme.

Post by Olivier Masson
Après, me débrouiller avec ce que j'ai, c'est simple. Mais j'aurais
voulu faire plus conventionnel pour apprendre. PHP5 ne le permettant
pas, on va faire du copier/coller.

Mauvaise idée AMHA. Cette solution aussi créée au moins autant de
problèmes qu'elle n'en "résoud".

[Mickael Wolff]

Post by Olivier Masson
Mais cette classe que je veux dériver l'a déjà été par d'autres pour
ajouter des fonctionnalités.
Chacun donne son petit nom et on se retrouve avec autant de nomq qu'il
existe de fonctionnalités supplémentaires.
class diet extends original
class crystal extends original
class sans-cafeine extends original
Donc, comment s'organise-t-on pour ajouter toutes les fonctionnalités
que l'on souhaite (une class diet + crystal + sans-cafeine) ?

Comme l'a dit Bruno, quelque chose inspiré du pattern decorator. Mais
dans ton cas, je pense qu'il faudrait récrire la hiérarchie avec un
système plus intelligent. Qui s'inspirerait du pattern composition
(composite). Mais c'est beaucoup de boulot, le copier-coller soit avec
toi si tu n'as pas le temps.