Constructeur & méthode virtuelle pure

Bonjour,

après deux jours passés à écumer internet à la recherche d'un moyen pour conjuguer constructeur & méthode virtuelle pure en C++, je viens appeler à l'aide ici.

Voici une description de mon problème :

dans le cadre du développement d'une application multi-tâche, je cherche le moyen de créer une classe générique pour manipuler une application gérant plusieurs choses comme les logs.

Partant de là, je souhaite pouvoir dans le constructeur de ma classe, laisser à son utilisateur la possibilité d'exécuter certaines actions par le biais de méthodes prédéfinies mais non-implémentées.

Le problème est que, venant de Java, j'ai commencé par bêtement créer des méthodes virtuelles pures appelées dans le constructeur. Malheureusement, l'ordre de création des objets en C++ est différent de celui de Java, et je me retrouve le bec dans l'eau à ne pas savoir comment obliger le constructeur de la classe mère à travailler avec les méthodes surchargées de la classe fille...

J'ai réussi à vaguement discerner dans les résultats que le pattern factory pourrait répondre à mon problème, mais je ne vois pas bien comment...


Merci pour votre aide !

Salut,

Citation:

---

Envoyé par Mobleu

Bonjour,

après deux jours passés à écumer internet à la recherche d'un moyen pour conjuguer constructeur & méthode virtuelle pure en C++, je viens appeler à l'aide ici.

Voici une description de mon problème :

dans le cadre du développement d'une application multi-tâche, je cherche le moyen de créer une classe générique pour manipuler une application gérant plusieurs choses comme les logs.

Partant de là, je souhaite pouvoir dans le constructeur de ma classe, laisser à son utilisateur la possibilité d'exécuter certaines actions par le biais de méthodes prédéfinies mais non-implémentées.

Le problème est que, venant de Java, j'ai commencé par bêtement créer des méthodes virtuelles pures appelées dans le constructeur. Malheureusement, l'ordre de création des objets en C++ est différent de celui de Java, et je me retrouve le bec dans l'eau à ne pas savoir comment obliger le constructeur de la classe mère à travailler avec les méthodes surchargées de la classe fille...

---

C'est bien simple: tu ne peux pas...

L'ordre de création des objets se fait dans l'ordre d'héritage: d'abord la classe mère (qui ne connait qu'elle) puis les classes dérivées (qui connaissent la classe mère).

Tant que l'objet "le plus dérivé" n'a pas été construit, il est strictement impossible de faire en sorte qu'un des comportements qui lui est spécifique soit utilisé.

Si tu déclares une fonction virtuelle (non pure) dans la classe de base, tu peux appeler cette fonction dans le constructeur de la classe mère, mais ce sera alors le comportement spécifique à la classe mère qui sera pris en compte ;)

Citation:

---

J'ai réussi à vaguement discerner dans les résultats que le pattern factory pourrait répondre à mon problème, mais je ne vois pas bien comment...

---

En fait, le pattern factory permet "uniquement" de n'avoir pas à s'inquiéter du type réel de l'objet que l'on va créer, afin de le considérer uniquement comme étant du type de la classe mère.

Autrement dit, il va permettre, lorsque tu l'utilises et que tu as des classes B, C, D,..., ZZ qui héritent de la classe A, de ne pas avoir à te soucier de savoir si l'objet réellement construit est de type B,C, D, ..., ZZ, mais de le considérer comme s'il s'agissait d'un objet de type A, et donc de n'avoir une dépendance que vis à vis de ce type A, à l'exclusion de tout autre. (la seule dépendance avec les types B, C, D,..., ZZ se trouvant au niveau de la fabrique elle-même).

Si tu veux qu'un comportement polymorphe, disponible dans l'interface publique de A, soit appelé sur tous les objets que la fabrique peut te renvoyer, tu peux soit faire en sorte que la fabrique appelle le comportement en question après avoir terminé de construire l'objet de type réel, mais avant de le renvoyer, soit appeler explicitement le comportement en question au départ de l'objet renvoyé par la fabrique dans la fonction qui reçoit l'objet créé, et ce, malgré le fait qu'il soit connu comme étant du type de base (le polymorphisme jouant alors ;))

Le fait d'appeler ce comportement au niveau de la fabrique permet, tu l'auras compris, d'avoir la certitude qu'il sera d'office appelé, mais il faut alors se poser la question de savoir ce qui pourrait arriver si, par erreur, l'utilisateur rappel le dit comportement de son coté.

Si cela risque de poser problème, l'idéal est sans doute de passer par une fonction virtuelle dans l'accessibilité privée et par une déclaration d'amitié de la fabrique envers la classe de base, et pour autant que l'objet créé soit connu de la fabrique comme étant du type de base (parce que l'amitié n'est ni transitive ni héritée), le polymorphisme faisant le reste ;)

Citation:

---

Envoyé par Mobleu

venant de Java, j'ai commencé par bêtement créer des méthodes virtuelles pures appelées dans le constructeur.

---

Même en java, c'est pas l'idée du siècle, amha...certes le late binding permet que la bonne méthode soit appelée, mais certaines caractéristiques de ta classe effective ne sont pas en place, vu que en java aussi, c'est le constructeur de la classe mère qui est appelé en premier. Autrement dit en faisant ça tu ouvres la porte à des comportement favorables aux bugs car contre-intuitifs...

Bon j'ai trouvé une solution pour contourner en partie le problème.

Elle ne fonctionne que parce que les méthodes que je souhaite fournir à l'utilisateur sont indépendantes de tout contexte du début à la fin.

J'ai finalement déporté les méthodes en question dans une nouvelle classe que j'ai appelée ClassInitializer.

Ensuite, j'ai modifié la classe pour la gestion des applications de manière à en faire un template. Du coup, lorsque l'utilisateur voudra créer un objet application, il précisera dans le constructeur le type d'objet fournissant les méthodes : soit l'objet de base fourni avec la classe, soit un objet dérivé de cet initialiseur.

Du coup, dans le constructeur, je suis alors capable d’instancier un initialiseur et d'appeler les méthodes fournies.

Bien évidemment, cette astuce ne fonctionne que parce que l'initialiseur n’interagit pas avec la classe fille qui, lors de l'appel du constructeur de la classe mère, n'est pas encore créée.

Il doit être possible de rajouter des fonctions à l'intialiseur en en faisant une inner-class de la classe mère, mais je ne me suis pas encore penché sur le problème...

Attention ! Il faut savoir que si vous utilisez Qt, et que la classe mère template appelle la macro QOBJECT, le compilo s'énerve. Pour contourner le problème, il faut créer une troisième classe, dérivée de la classe mère, qui fera office de surcouche template à la classe mère.