Couplage entre un module avec template et un module sans template

Bonjour à tous

Je sollicite votre avis sur un problème d'architecture, la solution que j'utilise me plait pas trop.
Pour résumé le problème : j'ai une application avec en autre 2 modules, un core (dépend que de la STL et Boost) et un module gui (qui dépend de Qt). Le core est templaté au maximum (de mes capacités... :aie:), la majorité des fichiers d'en-tête n'ont même pas d'include (autre que STL et Boost).
Forcement, ça coince avec Qt qui n'aime pas les templates. Je suis obligé d'inclure directement mes classes du core dans mes objets Qt, ce que j'aime pas trop (dépendance forte, instanciation des classes templates dans le main.cpp et dans la gui)

J'ai testé en appelant directement le core dans la gui, en appelant un classe wrapper qui appelle le core et appelé par la gui, ou en créant une classe d'interface qui est appelée dans le gui et une classe dérivée qui appelle le core. Ces différentes solutions me semblent pas géniales.

Quelqu'un a une solution ?

Merci

Salut,
Peux-tu donner un exemple concret car j'avoue ne pas forcément saisir ton problème.
A priori, j'aurais pensé à une interface avec une classe abstraite implémentée par ton template, mais je ne suis pas sur que ce soit vraiment la solution à ton problème :

Code:

---

1 2 3 4 5 6 7 8

class interface { public: void do()const{do_it();} virtual ~interface(); private: virtual void do_it()const=0; }

---

puis

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class toto> class tpl_interface : public interface { public: private: virtual void do_it()const { //blablabla t.some_thing(); // blablabla } toto t; }

---

Citation:

---

Envoyé par 3DArchi

Salut,
Peux-tu donner un exemple concret car j'avoue ne pas forcément saisir ton problème.
A priori, j'aurais pensé à une interface avec une classe abstraite implémentée par ton template, mais je ne suis pas sur que ce soit vraiment la solution à ton problème

---

Idem.

Je me demande même s'il y a réellement un problème en fait :)

Que des classes templates soient instanciées directement dans le code client, ça me semble être une obligation, puisque c'est dans leur ADN.

Après, peut-être que les classes n'ont pas besoin d'être template, auquel cas la création de classes wrapper non-template démontrerait ce point(*), mais c'est un autre débat.

Ceci dit, je te fais confiance. Ce n'est pas comme si tu avais commencé le C++ avant-hier :) Du coup, un exemple me permettrait de comprendre un poil mieux.

(*): si tu peux créer des classes wrapper non-template utilisables par le code client sans perte de fonctionnalité, pourquoi est-ce que les classes encapsulées sont des classes template?

@3DArchi
Non, tu sembles avoir bien compris mon problème.
C'est un des solutions que j'ai testé (sauf le NVI... pas bien surtout que j'ai passé 1 heure à expliquer à mes stagiaires les concepts, le NVI, le LSP, qu'il fallait tester les post et pré conditions, etc. :sm: auto flagellation)

Pour donner un exemple (j'espère plus claire) :
- dans mon module core, j'ai une structure de graph (boost::adjacent_list en interne avec des vertex_bundle et edge_bundle pour manipuler les données des vertices et edges, eux même étant des classes template avec de policies pour la gestion des types de vertices supportées, etc.) Il s'agit d'une simple chaîne de traitement, le graph est parcouru en remontant, chaque vertex implémentant un algorithme.
- dans mon module gui, j'affiche mon graph. (tout bêtement)

Le problème est que je vais avoir ma partie gui qui sera forcement dépendante d'une structure en particulier du graph. Récemment, j'ai modifié la politique d'exécution des algorithmes pour passer d'une version CPU à une version avec choix (CPU/GPU/etc.) Ce changement implique des options supplémentaires. Je n'ai pas eu d'autre choix que de modifier mes classes gui pour prendre en compte ces modifications (donc l'OCP à la poubelle).

Autre exemple, c'est l'utilisation d'expression template CPU/GPU (donc avec différentes politiques de création des données, de copies, de calcul).

Même si les modifications n'ont pas été trop problématique, je me demandais s'il était possible de faire "mieux".

Citation:

---

Après, peut-être que les classes n'ont pas besoin d'être template, auquel cas la création de classes wrapper non-template démontrerait ce point(*), mais c'est un autre débat.
(*): si tu peux créer des classes wrapper non-template utilisables par le code client sans perte de fonctionnalité, pourquoi est-ce que les classes encapsulées sont des classes template?

---

:koi: Le message subliminal est qu'on peut se passer des templates ? ;)

Plus sérieusement, a priori, les templates sont nécessaire je crois (par exemple, pour les types de données qui peuvent correspondre à des données côté CPU ou côté GPU, avec des traits et politques correspondant et utilisation dans les expressions template). Mais je suis quand même obligé d'avoir des wrappers non template, ce qui m'oblige à créer un wrapper pour chaque instanciation de template (donc nouveau argument template = nouveau wrapper... pas génial)

Salut,
Un simple et bête wrapper peut être pas. Mais une couche de présentation traduisant les éléments fonctionnels en éléments d'IHM Qt, ça ne me choque pas. Et cette partie est probablement assez concrète et soumise à variation dès que ton fonctionnel change.

Ok, merci pour les réponses. Donc je ne faisais pas trop n'importe quoi.

J'ai remarqué qu'il était possible d'utiliser les classes Qt comme template argument. Je vais voir si ça améliore le design et si ça apporte un plus.

Bon, ça fonctionne jusque maintenant (j'ai pas fini de refactoriser). Ça permet de mieux découpler mes modules. En particulier, je n'ai plus aucune dépendance à Qt dans mes modules, la dépendance à Qt est faite lors de l'instanciation dans le main, ce qui me permet de changer sans difficulté de bibliothèque (par exemple, utiliser asio à la place de QtNetwork)