Discussion :

[Akta3d]

Bonjour à tous,

Voici ma problématique:
Je souhaite créer une dll de Base à tous mes projets, appelons là Common.
Bien-sur, je ne vais pas réinventer la std ou autre lib.

J'aimerai justement choisir une api (Poco ou Qt dans mon cas) et surcharger toutes les classes que je risque d'utiliser dans mes projets.

Mes projets ne doivent pas avoir connaissance de l'api choisie. Ce qui me permettra dans le futur de changer facilement d'api par une autre en modifiant seulement le projet Common.


Quelle est la meilleur méthode?
- utiliser des #define dans tous les sens
- surcharger les classes qui m'interesse
J'opte pour le moment pour la 2eme solution

Je rencontre le souci suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Fichier MaClasseSurchargee.h
 
 
#include "API/NamespaceA/ClasseA.h"
 
namespace Common
{
	namespace NamespaceA
	{
		class Common_API ClasseA: public API::NamespaceA::ClasseA
		{
		};
 
	} //NamespaceA
} //Common

Si j'inclue MaClasseSurchargee dans un autre projet de plus haut niveau.
Ce projet à besoin de savoir où se trouve:
"API/NamespaceA/ClasseA.h"
Et je ne veux pas lui donner l'info

Et malheureusement je ne peux pas écrire:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
namespace API
{
	namespace NamespaceA
	{
		class ClassA;
	}
}
 
namespace Common
{
	namespace NamespaceA
	{
		class Common_API ClasseA: public API::NamespaceA::ClasseA
		{
		};
 
	} //NamespaceA
} //Common

Comment m'en sortir?
Je suis sur qu'il y a une solution simple.

[LittleWhite]

Bonjour,

Une solution que je propose, c'est de créer une classe "Contexte" dans laquelle les fonctions que vous voulez, sont.
Cette classe pourra être hériter, soit par ContexteQt, soit par ContextePoco. Ainsi, le programme ne jouera que avec l'interface Contexte et n'aura guère à se soucier si c'est du Qt ou du Poco.

Il existe une méthode similaire, reposant sur les templates, en place de l'héritage (classe de politique, je crois).

Sinon, en gros bourrin (que je déconseille), vous faites deux fois la même implémentation (la même classe / même fonction), une pour Poco et une pour Qt et vous incluant, soit l'une, soit l'autre (en jouant sur un #ifdef qui englobe les #include).

[Akta3d]

Merci de ta réponse,

Mais je cherche encore.

Ta première solution convient, si on ne souhaite utiliser que quelques méthodes de l'API de base, mais pour redéfinir une API complète je ne pense pas que soit la meilleur solution.
Énormément de classes et surtout de méthodes à réécrire, sans parler de l'héritage interne de l'API.


Je ne connaissais pas le concept des classes politiques, ou des classes traits, malgré qu'on les utilises souvent.
Petit lien pratique pour savoir ce que c'est: http://alp.developpez.com/tutoriels/traitspolicies/
D'un premier regard, je pense que je vais vite être coincé
Je regarde plus en profondeur, voir si je peux m'en sortir.


La dernière solution, comme tu les dis est a déconseillé.



Bon je cherche toujours.
Si je trouve une solution qui convient je posterai ma solution ici.



Je précise que je ne veux pas utiliser les 2 API en même temps.
C'est juste pour prévoir l'avenir. Lorsque les solutions évoluent et que d'énorme projets repose dessus et que l'on change l'API de base, tous les projets doivent être réécris. Je veux juste ajouter une couche d'abstraction à l'API de plus bas niveau.
(Exemple, d'anciens projets écrit en boost que l'on veux passer à Poco ou Qt.(Ce n'est qu'un exemple))

[LittleWhite]

Pour ce que vous faites (pouvoir changer une API de base), il faut une abstraction. L'abstraction, c'est le rajout d'une couche, entre votre application et l'API sous jacente.
Il n'y a pas grand choix de faire des surchages de chaque fonctions. Cela peut même être fait automatique avec un script ou un programme.

[oodini]

Les classes de politique sont une bonne solution.