Héritage et contraintes d'aggregation

Bonjour,
Sur un projet en cours (java 1.5), je suis en train d'écrire un package doté de 2 hiérarchies de classes :
- Les contenants, qui héritent d'une classe abstraite "Contenant"
- Les contenus, qui héritent d'une classe abstraite "Contenu"
Un contenant est associé à plusieurs contenus, et la relation est bidirectionnelle. Je souhaite utiliser la généricité de java 1.5.

Un exemple bateau de cette hiérarchie est présentée dans l'image jointe :
http://www.developpez.net/forums/att...1&d=1253018945

Le problème est que je souhaite mettre en place des contraintes entre contenants et contenus : dans l'exemple ci dessus, un disquaire ne doit contenir que des disques, et un libraire que des livres.

Pour cela, les associations doivent elles nécéssairement être placées dans les classes filles ? (CF image : http://www.developpez.net/forums/att...1&d=1253018955)

Ou y a t-il une solution possible en utilisant des contraintes de généricité avec java 1.5 ?

Moui.... on pourrait écrire:

Code:

---

1 2	class Librairie< L extends Livre> extends Boutique<L> { ...

---

avec

Code:

---

1 2 3

public abstract class Boutique<T extends ObjetAVendre> { }

---

mais je ne conseille pas ce genre d'implantation pour diverses raisons
.... en particulier pour une raison fonctionelle: (j'appelle ça l'argument "FNAC") il ne va pas falloir longtemps avant que le magasin vende autre chose que des Livres!:D

Merci !

1)Donc d'après ce que tu me dis, il vaut mieux en général garder une modélisation assez générale, sans contraintes, et laisser l'implémentation se charger de s'assurer que les types ajoutés dans les vecteurs sont corrects. C'est ça ?

2)Sinon si on garde le choix des contraintes de généricité, qu'est ce que cela donnerait du côté des ObjetsAVendre ? Comment typer de manière générique un disque pour qu'il ne soit vendu que chez un disquaire ?

J'ai essayé mais sans succès de rendre générique la classe ObjetAVendre à ta manière pour lui rajouter des contraintes :

Code:

---

public abstract class ObjetAVendre<T extends SegmentedFile>{...}

---

Mais là eclipse me demande de typer SegmentedFile dans l'expression "<T extends SegmentedFile>".
Après correction, ceci devient "<T extends SegmentedFile<FilePart>>", et eclipse me demande de typer FilePart, qui après correction donne etc...
bref, on tourne en rond.

Comment faire pour s'en sortir ? (Si ce n'est pas complètement abrerrant/idiot)

Citation:

---

Envoyé par phil512

Comment faire pour s'en sortir ? (Si ce n'est pas complètement abrerrant/idiot)

---

déclarer le type SegmentedFile avant ....
mais après ça va compliquer encore la déclaration de Boutique<T extends ObjetaVendre<?>>...

(euh voilà une paramétrisation étrange .... c'est quoi l'idée de SegmentedFile?)

Pardon c'est un copier coller un peu abusif. Voilà le message corrigé.

Merci !

1)Donc d'après ce que tu me dis, il vaut mieux en général garder une modélisation assez générale, sans contraintes, et laisser l'implémentation se charger de s'assurer que les types ajoutés dans les vecteurs sont corrects. C'est ça ?

2)Sinon si on garde le choix des contraintes de généricité, qu'est ce que cela donnerait du côté des ObjetsAVendre ? Comment typer de manière générique un disque pour qu'il ne soit vendu que chez un disquaire ?

J'ai essayé mais sans succès de rendre générique la classe ObjetAVendre à ta manière pour lui rajouter des contraintes :

Code:

---

public abstract class ObjetAVendre<T extends Boutique>{...}

---

Mais là eclipse me demande de typer SegmentedFile dans l'expression "<T extends SegmentedFile>".
Après correction, ceci devient "<T extends Boutique<ObjetAVendre>>", et eclipse me demande de typer FilePart, qui après correction donne etc...
bref, on tourne en rond.

Comment faire pour s'en sortir ? (Si ce n'est pas complètement abrerrant/idiot)

Si tu tiens absolument à mettre une contrainte, tu aurais intérêt à ne la mettre que sur l'une des classes.

1. Fonctionnellement, parce que sinon tes livres ne peuvent être vendus que dans des librairies ; tu me diras, c'est pas grave, je ferai du extends Librairie. Soit, mais si tu dois aussi vendre des Disques, tu es dans l'impasse :) Moralité, tu aurais tout à recoder.

2. D'un point de vue technique ça lie beaucoup trop fortement tes deux classes (au point où ça devient cyclique).