Discussion :

[FranckRav]

Bonjour,

je me pose des question existentielles sur la modélisation d'un "framework". Disons que j'ai dans mon framework deux Classes, A et B, associé par une composition 1-1.



Pour un projet donné, je dois surcharger la classe B qui devient B'



Comment faire pour que ce soit B' qui soit instancié quand j'instancis A dans mon projet, et non pas B? Je vois deux solutions:

- Le constructeur de A prend un objet en argument et je passe B'. C'est ok, mais ca peut poser des problèmes si j'ai des méthodes dans A qui retournent un objet B...

- Je surcharge A en A', précisant la nouvelle association avec B' et surchargeant les méthodes retournant B.



Bref, rien de très classe. J'ai choisi la deuxième méthode car elle est systématique mais franchement c'est très lourd, mon framework contenant une quarantaine de classes avec des associations dans tous les sens. Je me retrouve obligé de surcharger quasiment tout mon framework à chaque implémentation.

Quels conseils me donneriez vous?

Merci

[hed62]

- Le constructeur de A prend un objet en argument et je passe B'. C'est ok, mais ca peut poser des problèmes si j'ai des méthodes dans A qui retournent un objet B...

Ca ne pose pas de problème, puisque B' est un B , de par l'héritage.

[FranckRav]

oui c'est sur. Mais le soucis dans mon cas est qu'il y a de fortes chances que B' contienne des propriétés supplémentaires que B n'a pas. Le cast de B en B' n'est donc pas vraiment utilisable, parce que les attributs supplémentaires de B' ne seront pas initialisés...

[hed62]

Le cast de B en B' n'est donc pas vraiment utilisable

Ca c'est sur, je ne parlais bien sur que du cast de B en B'.
Sinon, je ne vois pas trop de solution à ton problme.. Mais peut être que tu utilises l'héritage à mauvais escient ?

[FranckRav]

Le fait de customiser une classe générique pour un projet ne serait pas de l'héritage?! Là je ne comprends plus l'OO!!

[hed62]

Plutôt que d'hériter, ne serait til pas possible d'utiliser la composition et de déléguer les traitements ? Si cela est possible, cela apporte plus de souplesse (car on maitrise la composition lors de l'exécution, contrairement à l'héritage)

Mais ce ne sont que des suggestions bien sur.

[FranckRav]

Hum, il faudrait que les classes de mon framework soient associées à toutes les classes de mes projets.... Dans mon exemple, que B soit associé à B', afin que lorsque j'instancie A, B et B' soient instanciés....

[Hephaistos007]

Il n'y a pas de solution puisqu'il n'y a pas de "problème", même si je comprends ton désarroi. Mais comprends bien que tu confères à un A la capacité de communiquer exhaustivement avec un B (c-a-d, toutes les méthodes de B peuvent être invoquées depuis A). Etendre B en B' est un choix qui t'appartient, toujours est-t-il que A n'a pas été prévu pour communiquer avec B'. En réalité, A peut quand même communiquer avec un B' en le considérant comme un B (c'est l'intérêt du polymorphisme), mais les méthodes propres à B' sont, de fait, totalement ignorées.

C'est un peu le marketing autour de l'orienté-objet qui porte à confusion. On fait croire que le mécanisme d'héritage permet d'étendre les fonctionnalités sans modifier l'existant (connu sous le nom de principe d'ouverture/fermeture). Ceci est vrai dans la toute première définition de l'héritage qui consistait uniquement à redéfinir dans une sous-classe, les comportements de la super-classe. Mais dans la définition "moderne" qui autorise aussi (et surtout) l'ajout de nouvelles méthodes, il faut évidemment modifier l'existant pour les exploiter !

[hed62]

Effectivement, sauf à implémenter un système (pas forcément complexe) d'introspection depuis A vers B', impossible de connaitre à l'avance l'ensemble des fonctionnalités des classes filles.

[FranckRav]

Oui, je comprends bien que l'ajout de nouvelles fonctionnalités impacte l'existant, surtout si on veut s'en servir!! En fait je veux juste poouvoir coder A de tel facon qu'elle puisse manipuler B ou B' de facon transparente, mais toujours dans le meme champ de fonctionnalités bien sur.

En fait nous avons mis en place un mécanisme proche du pattern Factory. Une classe s'occupe de faire les appels aux bons constructeurs, les classes du framework faisant appel aux méthodes de cette classe pour instancier. C'est simple et ca marche bien même si ca n'est pas complétement dynamique (si je surcharge une classe, il faut penser à surcharger la méthode correspondante dans la Factory)...