Problème de POO - Page 1

Bonjour,
Alors toujours sur mon interface graphique orientée objet (hé oui ^^) j'ai un problème qui peut paraître assez simple mais auquel je n'arrive vraiment pas à trouver de solution, il s'agit du suivant:

[URL=http://imageshack.us][IMG]http://img150.imageshack.us/img150/1984/img144us9.png[/IMG][/URL]

Voilà j'ai un composant graphique (par exemple un bouton) et un container pouvant contenir des composants (par exemple une fenêtre). Un container peut être considéré comme un composant en ce sens que traiter un container revient bêtement à traiter tous les composants qu'il contient relativement à lui-même.

Maintenant je voudrais faire un composant animé. Tout va bien, je crée un AnimatedComponent qui se base sur Component il et ajoute des fonctions qui le déplacent gentiment lorsqu'on fait un setPosition par exemple.

Maintenant le problème: j'aimerais faire pareil pour un Container. Or il se trouve que le code serait 100% identique, puisqu'un Container dispose des mêmes propriétés que le composant et le déplacer se fait de la même manière. Y'a-t-il un moyen de factoriser de manière à arriver à un résultat comme dans le schéma? (sans pour autant que le code devienne difficile à maintenir)

Pour l'instant je fais un truc moche: je n'ai qu'une seule classe AnimatedComponent qui hérite de Container car qui peut le plus peut le moins (un Container contenant zéro composant est un composant). Ainsi on perd la notion de Component/Container à ce niveau et c'est pas super propre

Merci d'avance pour votre aide

Bon, je connais pas trop la POO, mais il me semble que c'est un cas d'application de l'héritage multiple. Seulement Java ne supporte pas ce concept.

Je crois que l'utilisation des interfaces peut servir de palliatif pour ce genre de trucs (détails ici).

Ouai, grace aux Interfaces tu pourra utiliser Container comme si il héritait de Component et de AnimatedContainer, mais il faudra que Component ou AnimatedContainer soit une interface, et que tu déporte le code de l'Interface dans Container

en fait à chaque que l'on se trouve face à la tentation de faire de l'héritage multiple, la solution est la composition. Vouloir faire de l'héritage multiple est en fait vouloir manipuler plusieurs concepts et les merger en un seul, ce qui n'aide pas à la modularité. Dans ton modèle y a deux concepts: les objets graphiques et la dynamique de ces objets.
Donc en fait y'a deux classes principales: Container et MotionEngine. Et Container est composé d'une instance de MotionEngine.
En ensuite tu as:
* Component extends Container
* StaticMotionEngine extends MotionEngine
* AnimatedMotionEngine extends MotionEngine

Depuis qu'un collègue m'a convaincu que l'héritage multiple est la moins bonne des solutions, le code que je pond est toujours super modulaire et flexible. Par contre on se retrouve souvent à coder des Handler.handle....

Hum je vois oui, ta solution a l'air pas mal en fait. Faudrait que je voie ce que ça peut donner mais à mon avis je suis bon pour réviser le modèle entier... :/
Y'a juste un truc qui me chiffonne, c'est que là on est obligé de modifier le code de base (Component / Container), alors qu'on n'a pas forcément accès à la librairie (typiquement s'il s'agissait de Swing ce serait impossible). En plus ça implique d'alourdir le code de base en prévoyant d'avance toutes les fonctionnalités que les gens pourraient vouloir implémenter par-dessus un jour. Donc niveau modularité justement j'ai pas l'impression que ce soit bien/mieux...

Ben si tu n'as pas le controle sur Container, alors tu inverses la composition:
* class Container
* class Component extends Container
* class Animation composé d'un Container

Et en fait ca fait plus propre et simple comme ca

Hum... je vois.
Dommage quand même. Je peux pas simplement animer un container avec ça, je dois complètement changer l'interfaçage (on ne peut plus faire objetAnime.setPosition ou autres) à moins de faire que l'Animation soit un wrapper, mais bof pour l'évolutivité

Pas besoin de wrapper. Les fonctions spécifiques d'animation, tu les mets dans Animation (tu pourrais même en fait nommer cette classe AnimatedContainer), et tu ajoutes un getter dessus pour avoir le Container sous-jacent. Et si t'es en java 5, tu paramètres tout ca et tu perds pas le type de container que tu as mis dans l'animation.
Je vois pas où est la non évolutivité. Le seul inconvénient c'est que ca devient verbeux (animation.getContainer().draw()), mais bon ca c'est Java.

Ben justement si j'ai par exemple un bouton qui contient un Component Label (pour le texte) et que je veux le transformer en Label animé, je vais devoir changer tout ce qui utilise le label: label.setPosition -> label.getComponent().setPosition tu vois? Bref pas très pratique