Version imprimable
Bonjour,
Dans une hiérarchie d'objets j'aimerais pouvoir faire changer dynamiquement un objet de type. J'ai un objet B (objet applicatif) qui hérite d'un objet A (objet générique réutilisable).
Je ne peux donc pas mettre une méthode dans l'objet A du genre "changerEnB" sinon je ne le rendrais plus réutilisable.
De plus, j'ai lu à qq part que c'est très mauvais de vouloir faire changer le type d'un objet.
Comment dois-je procéder pour faire proprement (quitte à ne pas utiliser l'héritage) ?
le changement de type n'est en effet pas tres recommande (une cellule qui mute c'est souvent un cancer !) ... et pas possible pour les langages C++ / Java etc ...
et donc ? quelle(s) technique(s) peuvent être utilisées pour contourner le pb ?
au cas ou j'aurais mal compris tes intentions : tu veux un 'vrai' changement de type c.a.d. une mutation de l'instance, ou un cast ou equivalent ?
Prenons un cas concret.
Une application doit gérer une liste de produits (appellons-là "Appli")
Oui mais voilà : un produit est une notion, somme toute, relativement générique et donc réutilisable dans des contextes différents.
Une idée :
Utiliser deux classes : une classe Produit générique, et une classe ProduitAppli héritant de Produit, spécifique à l'application (car il contient par exemple un attribut ou une méthode qui est totalement propre à l'application).
Seulement, l'application doit pouvoir spécifier que tel ou tel produit fera ou non partie de l'application !
On aurait donc une liste de "Produit" que l'on pourra "muter" en "ProduitAppli" si on veut les intégrer dans l'application, d'où le problème.
Est-ce plus clair ?
si j'ai bien compris tu as une lib qui définie Produit et tu l'utilises dans ton appli qui elle veut finalement utiliser des ProduitAppli. Dans le cas les mutations sont inutiles : il faut qu'il y ai creation de ProduitApplis et jamais de Produits, meme si Produit ne le sait pas grace par exemple au design pattern 'fabrique'
ok j'vais voir du côté des design patterns.
Merci en tout cas ;)