Discussion :

[bolhrak]

Bonsoir,

Une petite question que je me pose d'un point de vue conception. Je souhaite réaliser une application graphique traitant différents type de documents, je pensais donc faire une classe DocumentManager par type de document, car certains auront des opération spécifiques en plus des classiques save, save_as, etc. De plus cela est pratique pour la création de documents puisque cette modélisation permet d'appliquer le pattern Factory Method. Les documents sont représentés par une hiérarchie de classe.

Chaque document manager contient une liste de documents, maintenant je n'arrive pas à choisir entre les deux implémentations suivantes :

1] La classe mère de la hiérarchie de DocumentManager contient une list de Document, classe mère de la hiérarchie de classes pour les documents. Cela évite d'avoir à réécrire les opérations générales de gestion des documents dans chaque DocumentManager. Le hic c'est que pour les opérations spécifiques, chaque DocumentManager devra sous-caster les éléments de la liste à chaque utilisation, ce qui ne me plaît pas beaucoup.

2] La classe mère de la hiérarchie de DocumentManager ne contient que des méthodes virtuelles pures, ensuite vient une classe d'implémentation paramétrable par le type de documents, du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
template <Document> DocumentManager {
//...

L'avantage est que le code de gestion des Documents est écrit une seule fois, et que l'on ne perd pas le type de documents que l'on gère. Maintenant la classe de base de la hiérarchie de Document devient alors inutile, et je trouve que l'on perd en clarté : à chaque définition de Document, au lieu d'avoir une API à consulter pour savoir quelles méthodes réimplémenter, on implémente les méthodes selon les erreurs générées par le compilateur :s

Il y a sûrement d'autres avantages/inconvénients que je n'ai pas vus, d'où ma question :p

[JolyLoic]

Je préfère la 2. L'intérêt de la classe de base est de définir une interface qui te permettra par exemple de mettre tous tes DocumentManagers dans un seul et même conteneur, pour par exemple itérer sur les types disponibles dans une boîte de dialogue "fichier/nouveau".

Pour ce qui est de la duplication de code :
- Vu que c'est templaté, il y a peut-être duplication par le compilateur, mais pas duplication de code source, ce qui est bien moins problèmatique.
- Si cette duplication de code objet est néfaste (je ne pense pas dans ce cas, mais pour des classes instanciées avec plein de types, dans un environnement très contraint, ça peut être le cas), il y a des techniques pour éviter ça, sans modifier en rien l'interface de tes classes.

Pour le fait que ce qui est demandé d'un Document soit moins explicite, rien n'empêche de garder une classe de base d'un document, toujours pour les cas où tu veux traiter les document en bloc, sans connaitre leur véritable type.

[bolhrak]

Je préfère la 2. L'intérêt de la classe de base est de définir une interface qui te permettra par exemple de mettre tous tes DocumentManagers dans un seul et même conteneur, pour par exemple itérer sur les types disponibles dans une boîte de dialogue "fichier/nouveau".

C'est exactement ce que je compte faire :p Maintenant la classe de base n'est pas spécifique à la solution 2, dans le cas de la solution 1 j'utilise le même principe, seulement aucun DocumentManager ne connaîtra le type exact des Documents dans la liste.

Pour ce qui est de la duplication de code :
- Vu que c'est templaté, il y a peut-être duplication par le compilateur, mais pas duplication de code source, ce qui est bien moins problèmatique.
- Si cette duplication de code objet est néfaste (je ne pense pas dans ce cas, mais pour des classes instanciées avec plein de types, dans un environnement très contraint, ça peut être le cas), il y a des techniques pour éviter ça, sans modifier en rien l'interface de tes classes.

Aucune contrainte de ce côté là, par contre si tu as un lien ou une explication rapide sur comment faire ça m'intéresse quand même.

Pour le fait que ce qui est demandé d'un Document soit moins explicite, rien n'empêche de garder une classe de base d'un document, toujours pour les cas où tu veux traiter les document en bloc, sans connaitre leur véritable type.

Effectivement avec ce petit ajout je ne vois plus d'inconvénients à la seocnde méthode.

Merci beaucoup pour la réponse

[JolyLoic]

En gros, l'idée est de faire partager à tous un groupe de type une seule implémentation. Par exemple, on défini l'implémentation pour MaClasse<void*> (éventuellement en spécialisant si nécessaire), puis on utilise la spécialisation partielle pour définir que tous les MaClasse<T*> sont construits à base de MaClasse<void*> sur laquelle on ajoute une légère surcouche pour faire du cast. Cette surcouche sera selon toute probabilité inlinée, et donc une seule définition existera pour tous les T*.

C'est un peu ce qui est fait en Java, ou en C# (du moins pour les ref types) où les génériques ne servent qu'à ajouter une couche de cast autour d'une implémentation unique à base de l'équivalent local de void*, Object.

[Jean-Marc.Bourguet]

Dans la solution 2, rien empèche la classe de base d'avoir des membres implémentés et d'imposer que les Document héritent d'une classe AbstractDocument. Il est possible que ça corresponde mieux au problème. Si ce n'est pas le cas, en utilisant l'héritage privé c'est une autre façon d'éviter la duplication de code.

[bolhrak]

JolyLoic : ok, mais dans ce cas on retombe dans le problème où on est obligé de sous caster les documents dans la liste lorsqu'on les récupère non ?

Jean-Marc : C'est effectivement ce que j'ai fait, ça me permet de pouvoir effectuer des manips générales sur les documents depuis une classe gérant les DocumentManager. Par contre même avec l'héritage privé je ne vois pas trop comment on évite la duplication de code (du moins dans l'exemple qui m'intéresse) sans perdre le type réel des Documents stockés.

[Jean-Marc.Bourguet]

En mettant une couche se contentant de faire les cast nécessaires dans la classe template.

Je ne vois pas comment éviter la duplication et les casts.