Discussion :

[cob59]

Bonjour � tous,

Supposons que je code une API de ce type :

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
//classe abstraite
class ServiceResource {
	static ServiceResource* Create();
	static void Destroy(ServiceResource* res);
 
protected:
	~ServiceResource();
}
 
//classe abstraite
class Service {
	static Service* Create();
	static void Destroy(Service* res);
 
	virtual void connect(ServiceResource* res) = 0;
 
protected:
	~Service();
}

Utilis�e de cette mani�re :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
// Allocation
Service* srv = Service::Create();
ServiceResource* res = ServiceResource::Create();
 
// Acquisition de la ressource par le service
srv->connect(res);
 
// Utilisation du service
...
 
// Désalloc
ServiceResource::Destroy(res);
Service::Destroy(srv);

J'aimerais qu'� l'appel de ServiceResource::Destroy(res), l'objet srv qui utilise cette ressource s'en "d�sabonne", par un syst�me de callbacks ou autre.

Pour l'instant je proc�de ainsi, ServiceImpl et ServiceResourceImpl �tant les deux classes concr�tes impl�mentant mon API :

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
 
void ServiceImpl::connect(ServiceResource* res) {
	ServiceResourceImpl* resimpl = dynamic_cast<ServiceResourceImpl*>(res);
	if (resimpl != nullptr) {
		// Pour que la ressource sache quel service l'utilise, et puisse notifier le service pour qu'il s'en désabonne si la ressource est détruite
		// (nb: idéalement il faudrait remplir un pool de services, pour gérer le cas d'abonnements multiples à une ressource, mais passons)
		resimpl->setService(this);
	}
	this->resource = res;
}
 
void ServiceResource::Destroy(ServiceResource* res) {
	ServiceResourceImpl* resimpl = dynamic_cast<ServiceResourceImpl*>(res);
	if (resimpl != nullptr) {
		// "nullptr" pour que le service comprenne qu'il n'est plus connecté à aucune ressource.
		resimpl->getService()->connect(nullptr);
	}
	delete res;
}

Mes classes concr�tes disposent donc de pointeurs en attributs (et des get/set associ�s) pour se d�signer l'un l'autre, de mani�re � ce que le service connaisse l'adresse de la ressource et inversement.

Mais comme vous avez pu le remarquer, j'utilise des dynamic_cast, donc RTTI, ce que j'aimerais �viter. Connaissez-vous une solution alternative, un design pattern que j'aurais manqu� ?

Contraintes :

• Pas de types STD/BOOST dans le header de mon API ; en fait je n'y inclus rien.
• Si possible, ne pas trop polluer les classes de l'API. L'abonnement doit �tre transparent pour l'utilisateur (quoique, si vous avez un avis diff�rent sur ce dernier point, je vous �coute).

[Klaim]

Et si tu utilisais std::shared_ptr, potentiellement en combinaison de std::weak_ptr? mal lu la contrainte

De toutes facons ton systeme ne marchera jamais correctement sans une forme de smart pointer. Toutes les alternatives sont a la fois intrusives et visible par l'utilisateur.

Au pire fait toi ton propre smart pointer mais franchement c'est pas evident.

Une alternative a ton systeme, mais dont l'interet depends totalement de si tu as vraiment besoin de pointeurs dans ton service, c'est de passer par un simple id de resource au lieu d'un pointeur.

Comme ca ton service doit toujours recuperer l'objet quand il en a besoin et l'utiliser seulement si il est trouve.

Cela dis, les deux aproches que tu as sont pour moi completement unsafe en tout cas si c'est du multithread