Singleton & Smart_pointer

Version imprimable

Bonjour,

Le tuto n'offre pas de solutions pour r�aliser des singletons en passant par des smart pointer.
Comment peut-on s'y prendre?

Actuellement mes tests donne:

.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
class Ressources_Manager : boost::noncopyable{
public:
	static boost::shared_ptr<Ressources_Manager> Instance();
	virtual ~Ressources_Manager();
 
 
private:
//	boost::shared_ptr<Ressources_Manager> operator= (const boost::shared_ptr<Ressources_Manager>){}
	Ressources_Manager();
	Ressources_Manager (const Ressources_Manager&);
 
	static boost::weak_ptr<Ressources_Manager>  m_instance;
 
	sf::Texture H_Sp_Prairie;
	sf::Image   Img_H_Prairie;
 
	void Load_Textures();
	void Load_Images();
};

.cpp

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
	boost::shared_ptr<Ressources_Manager> Ressources_Manager_ptr = Ressources_Manager::Instance();
//	Ressources_Manager Ressources_Manager::m_instance=Ressources_Manager();
 
		Ressources_Manager::Ressources_Manager() {
 
			Load_Images();
			Load_Textures();
		}
 
		Ressources_Manager::~Ressources_Manager() {
 
		}
 
		boost::shared_ptr<Ressources_Manager> Ressources_Manager::Instance()
		{
 
			  boost::shared_ptr<Ressources_Manager> instance = m_instance.lock();
			  if (!instance) {
			    instance.reset(new Ressources_Manager());
			    m_instance = instance;
			  }
			return instance;
		}
 
		void Ressources_Manager::Load_Images()
		{
			Img_H_Prairie.loadFromFile("Image/HexaTestSize.bmp");
			Img_H_Prairie.createMaskFromColor(sf::Color(255,255,255));
		}
 
		void Ressources_Manager::Load_Textures()
		{
			H_Sp_Prairie.loadFromImage(Img_H_Prairie);
		}

Erreur affich�e:
../RessourcesManager.cpp:29: undefined reference to `itpro::ress::Ressources_Manager::m_instance'

21/10/2015, 13h14
dragonjoker59
Bon, pour commencer, ton instance ne devrait pas �tre stock�e dans un weak_ptr, car une fois sorti de ta fonction Instance(), le shared_ptr est d�truit, et comme il est la seule strong reference sur l'instance, celle-ci est d�truite.
Ensuite, utilise boost::make_shared plut�t que ptr.reset( new... ).
~~Pour ton erreur de link, c'est simplement d� au fait que tu d�clarais m_instance en tant que weak_ptr et tu l'impl�mentais en tant que shared_ptr~~

EDIT:
Code:

1 2 boost::shared_ptr<Ressources_Manager> Ressources_Manager_ptr = Ressources_Manager::Instance(); // Ressources_Manager Ressources_Manager::m_instance=Ressources_Manager();
Que cherches-tu � faire l�? Pourquoi m_instance a-t-elle chang� de nom?
25/10/2015, 10h53
JolyLoic

Je ne suis pas certain que singleton et shared pointers aillent bien ensemble (sans compter que le singleton st souvent un anti-pattern) : Tu va avoir un singleton qui va �tre d�truit d�s que personne ne l'utilise, et se reconstruire � chaque utilisation. Difficile dans ces cas l� de garder de l'�tat d'une utilisation � l'autre, et sans �tat � garder et � partager, � quoi sert un singleton ?

Pour ton probl�me de link, j'imagine que c'est parce que tu as d�clar� ta variable statique dans ton .h, mais que tu ne l'as d�finie nulle part. Ajoute dans ton .cpp:

Code:

boost::weak_ptr<Ressources_Manager> Ressources_Manager::m_instance;

http://cpp.developpez.com/faq/cpp/?p...tion-des-liens

Sinon, ta fonction Instance n'est pas thread-safe : Qu'arrive-t-il si, alors que ton weak_ptr est vide, deux personnens demandent simultan�ment acc�s � Instance ? Tu risques de cr�er deux shared_ptr diff�rents...
27/10/2015, 18h00
Hyssgrif

Bonjour,

Merci pour vos r�ponses,
En faite je n'ai pas besoins d'utiliser des threads pour cette class, mais je souhaite en faire un singleton pour ne l'initialis�e q'une seule fois et pouvoir l�instancier un peut partout dans mon projet comme s'il s'agissait d'une variable globale.
Je me suis un peut aventur� avec les weak_ptr sans savoir ou j'allais en suivant un code trouv� sur internet.
En revanche je souhaiterais vraiment faire appel aux smart_ptr soit les shared_ptr pour partager cette classe avec les autres ressources de mon programme.
Je n'ai pas encore trouv� la solution.

Merci � vous
27/10/2015, 18h22
Hyssgrif

Pb r�solue,

Merci � vous ;)
27/10/2015, 21h15
koala01
Salut,

Citation:

Envoy� par Hyssgrif

Bonjour,

Merci pour vos r�ponses,
En faite je n'ai pas besoins d'utiliser des threads pour cette class, mais je souhaite en faire un singleton pour ne l'initialis�e q'une seule fois et pouvoir l�instancier un peut partout dans mon projet comme s'il s'agissait d'une variable globale.
Je me suis un peut aventur� avec les weak_ptr sans savoir ou j'allais en suivant un code trouv� sur internet.
En revanche je souhaiterais vraiment faire appel aux smart_ptr soit les shared_ptr pour partager cette classe avec les autres ressources de mon programme.
Je n'ai pas encore trouv� la solution.

Merci � vous

Je me permet de revenir sur cette discussion, mais, � lire ton intervention, j'ai envie de te poser une seule question:

Pourquoi voudrais tu pouvoir utiliser une variable comme si elle �tait globale (que ce soit sous la forme d'un singleton ou non) :question:

Car, d'exp�rience:
1. aucune variable ne doit effectivement �tre accessible depuis partout dans le code
2. le simple fait de permettre � "n'importe quelle fonction" d'aller chipoter � une variable rend le code particuli�rement difficile � d�buger
Le plus simple, si tu veux t'assurer qu'une variable ne sera cr��e qu'une fois, c'est encore de faire en sorte d'avoir cette garantie par la construction de ton code (en veillant � ce qu'il n'y ai qu'une seule d�claration de la variable du type indiqu�) et de veiller � la transmettre sous la forme d'une r�f�rence (�ventuellement constante) � "tout ce qui pourrait en avoir besoin" ;)
08/11/2015, 14h18
Hyssgrif

Salut Koala01,

En r�alit�, l'objectif finale et de cr�er une classe dans une biblioth�que qui aurait pour r�le de charger une fois et une seule des ressources au d�but du programme, les stocker et les rendre disponibles un peut partout dans le code.
Ici je charge des images, textures et autres..
Je veux que ces ressources soient accessibles par certaine parties du programme sans avoir a recr�er la classe et donc recharger ces ressources
09/11/2015, 02h30
koala01
Citation:

Envoy� par Hyssgrif

Salut Koala01,

En r�alit�, l'objectif finale et de cr�er une classe dans une biblioth�que qui aurait pour r�le de charger une fois et une seule des ressources au d�but du programme, les stocker et les rendre disponibles un peut partout dans le code.

Oui, c'est g�n�ralement ce que l'on attend de la part d'un singleton...

Sauf que, si tu y regarde d'un peu plus pr�s, il n'y a aucune ressource qui m�rite r�ellement d'�tre rendue accessible depuis "n'importe o� dans le programme":
- Les sons ne sont utiles que pour le module sons
- les textures / images/ donn�es permettant de tracer diff�rents �l�ments ne sont utiles que dans le module d'affichage
- la connexion � un serveur externe n'est utile que dans le module ... net
- et je pourrais continuer longtemps comme cela.
Citation:

Ici je charge des images, textures et autres..
Je veux que ces ressources soient accessibles par certaine parties du programme sans avoir a recr�er la classe et donc recharger ces ressources

Tu n'as ni � les rendre disponibles depuis n'importe o� (renseigne toi peut �tre sur le mod�le MCV, ce genre de donn�es faisant clairement partie de la vue ;) ), ni � recr�er l'instance de la classe qui les maintient en m�moire ou � les recharger : tu dois surtout d�terminer le meilleur endroit pour cr�er une et une seule instance de cette classe et �tre en mesure de la transmettre � "qui en a besoin" ;)

Peut �tre devrais tu lire deux tickets de blogs d'emmanuel deloget :
le premier est au sujet de la singletonite
et le deuxi�me est au sujet de la gestion des gestionnaires

Notes que, de mani�re g�n�rale, l'utilisation de termes comme "gestion", "gestionnaire", "management", et autre dans une �tude de besoins s'av�re souvent beaucoup trop vague que pour permettre de mod�liser de telles notions "telles quelles" : la responsabilit� de ce genre de notions est tellement mal d�finie que l'on finit par se retrouver avec quelque chose de monolithique, impossible � faire �voluer car s'occupant de beaucoup trop de choses ;)
09/11/2015, 11h45
foetus

Citation:

Envoy� par koala01

Tu n'as ni � les rendre disponibles depuis n'importe o� (renseigne toi peut �tre sur le mod�le MCV, ce genre de donn�es faisant clairement partie de la vue ;) ), ni � recr�er l'instance de la classe qui les maintient en m�moire ou � les recharger : tu dois surtout d�terminer le meilleur endroit pour cr�er une et une seule instance de cette classe et �tre en mesure de la transmettre � "qui en a besoin" ;)

Le probl�me du singleton ce sont les responsabilit�s: qui peut le lire, qui peut l'�crire

Un MVC n'est pas forc�ment utile, parce que tu peux encapsuler ton singleton dans ta classe principale [celle qui fait office de god class] et c'est elle qui va le cr�er, le d�truire et le transmettre.

Citation:

Envoy� par koala01

Notes que, de mani�re g�n�rale, l'utilisation de termes comme "gestion", "gestionnaire", "management", et autre dans une �tude de besoins s'av�re souvent beaucoup trop vague que pour permettre de mod�liser de telles notions "telles quelles" : la responsabilit� de ce genre de notions est tellement mal d�finie que l'on finit par se retrouver avec quelque chose de monolithique, impossible � faire �voluer car s'occupant de beaucoup trop de choses ;)

Un manager ou gestionnaire peut �tre juste une classe d�l�gu�e vers des objets qu'il contient (c'est lui qui les cr�e et les d�truit ce qui peut-�tre pratique pour avoir 1 [grosse] portion de ton code qui centralise cela) :mrgreen:

Et juste avec un param�tre tu peux choisir vers quel objet tu vas faire ta d�l�gation
09/11/2015, 14h51
koala01
Citation:

Envoy� par foetus

Le probl�me du singleton ce sont les responsabilit�s: qui peut le lire, qui peut l'�crire

Tout � fait.

Mais le probl�me est que tu arriveras tr�s rapidement � vouloir y acc�der -- ne serait-ce qu'en lecture -- � peu pr�s partout. Et c'est logique : il est par nature pr�vu pour �tre accessible depuis n'importe o�!

Et bien sur, plus tu voudras l'utiliser n'importe o�, plus tu auras tendance � lui donner des responsabilit�s qu'il n'a pas � avoir. Et l� encore, c'est logique : il s'appellera tr�s souvent XxxManager (*), et tu sera tr�s souvent tent� de te dire que "mais en fait, mon XxxManager, il g�re les Xxx... Et telle fonctionnalit� fait partie de la gestion des Xxx..."

R�sultat des courses, tu vas te retrouver avec une classe qui fait �norm�ment (beaucoup trop) de choses et qui est utilis�es quasiment partout, ce qui va � l'encontre de deux des principaux principes SOLID : le SRP et l'OCP.

Et, au final, tout ton projet d�pendra d'une mani�re ou d'une autre de ton singleton, il sera quasiment impossible de faire �voluer ton projet sans passer par une modification de celui-ci.

Sauf que, tu auras quasi syst�matiquement des modifications "mineures" au niveau de ton singleton qui "casse" au moins une chose (parfois m�me sans que tu ne t'en rende compte) au niveau de ton projet.

Citation:

Un MVC n'est pas forc�ment utile,

C'est un mod�le d'architecture qui pr�sente l'�norme avantage qui tend � s�parer clairement les diff�rents �l�ments en fonction des diff�rents modules et � r�duire tr�s fortement les d�pendances entre les diff�rents �l�ments. Et rien qu'en cela, c'est un mod�le particuli�rement int�ressant � suivre

Citation:

parce que tu peux encapsuler ton singleton dans ta classe principale [celle qui fait office de god class] et c'est elle qui va le cr�er, le d�truire et le transmettre.

Quelle horreur!!!

Je sais que �a date, mais tu devrais relire mes interventions au sujet des god_objects (note que j'ai m�me encore �norm�ment �volu� depuis et que je pourrais motiver mon malaise � ce sujet de mani�re bien plus claire maintenant ;) )

Citation:

Un manager ou gestionnaire peut �tre juste une classe d�l�gu�e vers des objets qu'il contient (c'est lui qui les cr�e et les d�truit ce qui peut-�tre pratique pour avoir 1 [grosse] portion de ton code qui centralise cela) :mrgreen:

Et juste avec un param�tre tu peux choisir vers quel objet tu vas faire ta d�l�gation

(*)
He bien, selon toi, quelles fonctionnalit�s un RessourceManager (vu que c'est ce que Hyssgrif voudrait faire) devra-t-il fournir ?

Commen�ons simple :
1. les textures, c'est des ressources : il devra les g�rer
2. les sons, c'est des ressources : il devra aussi les g�rer
3. les descriptions d'objets devrant �tre affich�s (les points qui les composent et les vertices qui relient ces point) sont aussi des ressources : il devra les g�rer
4. les entr�es / sorties, c'est aussi des ressources : il devra les g�rer
5. (qui sait : ) une connexion � un serveur au travers d'internet, c'est aussi une ressource
6. une base de donn�e, pareil
7. Et le pire de tout, c'est sans doute la configuration, parce que c'est une ressource qui permet de d�finir comment les autres ressources seront utilis�e
8. ... je pourrais surement trouver un tas d'autres ressources
Et, comme tu n'a pas clairement d�sign� le type de ressource que ton manager devait g�rer, � chaque nouvelle ressource que tu vas cr�er, tu vas avoir tendance � la faire g�rer par... ton gestionnaire de ressources, m�me si le type de ressource que tu ajoute � ton manager n'est pas sens� �tre utilis� aux m�mes endroits que les ressources qu'il g�re d�j�.

Tout cela aura pour r�sultat assez malsain de te conforter dans l'id�e que "ton gestionnaire de ressources doit �tre accessible depuis n'importe o�". Pourquoi malsain? me demandera tu ? Simplement parce que cela va cr�er un certain nombre de d�pendances qui n'ont absolument aucune raison d'�tre : la partie qui s'occupe de l'affichage n'a absolument aucune raison d'avoir acc�s aux sons ou � la base de donn�es qui seront rendus disponibles au travers de ton gestionnaire.

Et toutes ces d�pendances qui n'ont pas lieu d'�tre finiront forc�ment par transformer ton projet en un "tout monolithique" sous peine d'aller casser quelque chose � chaque fois que tu veux ajouter une fonctionnalit� quelconque.

Mais le pire, dans tout cela, c'est que je n'ai m�me pas encore abord� le probl�me de la signification m�me du terme manager! En effet, un manager, ca doit g�rer quelque chose. Mais, si on prend l'exemple des textures, g�rer les textures, cela revient � faire un certain nombre de choses � savoir:
1. cr�er des textures (sans doute de diff�rents types)
2. charger des textures (sans doute de diff�rents formats)
3. maintenir les textures en m�moire et les rendre accessibles pour "qui en a besoin"
Le (1) nous introduit la notion de factory; le (3) nous introduit celle d'un loader, le (3) nous introduit celle de "collection" (add, remove, getElement, ...) et, vu que tu n'as pas pris la peine de pr�ciser exactement quelle responsabilit� prenait ton gestionnaire (de textures), tu voudras "logiquement" lui donner ces trois responsabilit�s qui auraient du �tre distinctes.

Si bien que l� o� tu n'aurais du pouvoir acc�der qu'aux textures existantes, tu pourras aussi acc�der � la cr�ation et au chargement de nouvelles textures. Or, si tu donne la possibilit� � "quelqu'un" de profiter des fonctionnalit�s de cr�ation et de chargement de nouvelles textures, ce n'est qu'une question de temps avant que ce "quelqu'un" ne d�cide de les utiliser, m�me si il est dans une situation dans laquelle tout ce qu'il aurait du pouvoir faire c'est... acc�der aux textures existantes.

Et le r�sultat ne se fera pas attendre : tu te retrouveras tr�s rapidement avec trois, cinq ou dix endroits o� "quelqu'un" d�cide de charger ou de cr�er une texture.

Et c'est l� que les probl�mes vont commencer, parce que, comme tu auras plusieurs endroits o� "quelqu'un d�cide de charger ou de cr�er une texture", si tu as un probl�me de chargement ou de cr�ation de texture, tu es pour ainsi dire certain d'oublier l'un des endroits du code o� le processus est lanc� lorsque tu voudras corriger le probl�me.

Et, bien sur, tout ce que j'ai dit pour les textures est tout aussi valable -- avec peut �tre quelques arrangements sp�cifiques -- pour tous les types de ressources que j'ai cit� (et pour tous ceux que je n'ai pas cit� ;) )

Le meilleur conseil � donner est donc : fais des petites classes aux responsabilit�s clairement �tablies (TextureFactory, TextureLoader, TextureHolder, SoundFactory, SoundLoader, SoundHolder, ...) qui pourront d�s lors �tre utilis�es sans arriver avec tout un cort�ge de fonctionnalit�s dont on n'a pas besoin et qui ne seront transmises (pour les XxxHolder, essentiellement) qu'aux �l�ments qui en ont vraiment besoin et, pour les autres, qui ne seront accessibles (et �ventuellement, dont une instance ne pourra �tre cr��e) que pour/par les �l�ments qui prennent en charge un processus particulier au niveau de la gestion d'une ressource particuli�re.

En "subdivisant" les responsabilit�s aff�rentes � tes diff�rents manager (ou pire, aff�rentes � ton unique RessourceManger) en autant de classes prenant chacune une responsabilit� sp�cifique, tu te rendras compte que:
1. tu n'as absolument plus aucun besoin de disposer de "quelque chose qui soit accessible de partout"
2. ton code sera globalement beaucoup plus simple
3. ton code pr�sentera globalement beaucoup moins de risques d'erreurs (logique : le risque d'erreur est au moins proportionnel au nombre d'instructions d'une fonction particuli�re)
4. ton code sera beaucoup plus susceptible d'�tre test� int�gralement (les tests unitaires, c'est un outil particuli�rement n�cessaire en d�veloppement ;) )
5. ton code sera beaucoup plus facile � d�buger et � faire �voluer
6. les d�pendances entre les diff�rentes fonctionnalit�s de ton projet seront beaucoup plus simples, et donc plus facile � prendre en compte
Et tout cela, grace au simple respect de deux des principes SOLID : le SRP et l'OCP ... Avoue que c'est pas mal comme perspective, non :question:
15/11/2015, 16h55
foetus
Je ne suis pas d'accord :mrgreen:

Lorsque je parle de "god object" (peut-�tre � tord) c'est l'objet principal que certaines biblioth�ques (surtout IHM comme Qt, VCL) ont besoin pour lancer l'application (et initialiser la fen�tre principale).
Et je ne parle pas d'h�ritage, polymorphisme, h�ritage multiple, ou autre ... juste de l'utilisation de cette classe principale (*).

Donc je trouve "�trange" que pour respecter les principes SOLID SRP OCP ou autres, on ne doit pas profiter de cette grosse classe (et de sa commodit�).
Surtout qu'un de ses r�les c'est l'initialisation au lancement (entre autres comme thread d'affichage ou les gros traits/ lignes de la logique IHM)
Les managers sont d'ailleurs essentiellement initialis�s au d�marrage.

Et lorsque tu parles de MVC, je voulais te faire remarquer que cette grosse classe peut faire office de contr�leur et ton manager de mod�le.
Apr�s, pour diff�rentes raisons (temps de d�marrage, maintenance, �volution...), tu peux le faire �voluer en un vrai MVC.

Citation:

Envoy� par koala01

Et, au final, tout ton projet d�pendra d'une mani�re ou d'une autre de ton singleton, il sera quasiment impossible de faire �voluer ton projet sans passer par une modification de celui-ci.

Sauf que, tu auras quasi syst�matiquement des modifications "mineures" au niveau de ton singleton qui "casse" au moins une chose (parfois m�me sans que tu ne t'en rende compte) au niveau de ton projet.

J'ai d� mal � voir un projet/ application avec lequel/ laquelle toutes les classes ont tr�s peu de d�pendances :whistle:
D�j� la classe principale (*) est un contre-exemple.

Ou alors un petit projet, une petite application.

Parce que c'est bien joli d'avoir une arm�e de classes � 1 responsabilit�, de pouvoir les tester individuellement (**), etc..., mais apr�s il faut mettre en place tout le ciment pour cr�er/ d�truire et aussi passer le bon objet. Sans parler de ton projet qui explose en terme de classes/ fichiers.
Ton exemple de classes: TextureFactory, TextureLoader, TextureHolder, SoundFactory, SoundLoader, SoundHolder, ... cela fait un peu peur :? :?

Une mise en situation: tu codes un jeu et tu dois prendre en compte 3 types de textures (png, DXT je-ne-sais-pas-quoi, et autre chose) et 2 types de sons.

Au lieu d'avoir 5 grosses classes + 1 manager "classe d�l�gu�e" (mais il y a s�rement d'autres fa�ons de coder) (et je signale au passage que si tu cherches un algo par rapport au mp3 ou au png, tu sais exactement o� il est) tu vas avoir (3xX + 2xY) classes.
Sans parler du fait que rien pour g�rer tout cela tu vas mettre en place de l'h�ritage (certes simpliste), mais un h�ritage quand m�me. Donc (3xX + X + 2xY + Y) classes

Je pr�vois d�j� que tu vas me r�pondre que ton IDE c'est le plus puissant de la terre (VIM, Visual, ...) que tu t'en fiches tu g�res X projets en m�me temps (donc tu n'es pas � quelques classes en plus) et que je n'ai jamais cod� sur/ maintenu un gros projet monolithique.

Et je peux rajouter que je code que des applications pas des biblioth�ques mais avec de la conception pour reprendre et r�utiliser "une colonne vert�brale".
Citation:
Envoy� par koala01

les textures, c'est des ressources : il devra les g�rer
les sons, c'est des ressources : il devra aussi les g�rer
les descriptions d'objets devrant �tre affich�s (les points qui les composent et les vertices qui relient ces point) sont aussi des ressources : il devra les g�rer
les entr�es / sorties, c'est aussi des ressources : il devra les g�rer
(qui sait : ) une connexion � un serveur au travers d'internet, c'est aussi une ressource
une base de donn�e, pareil
Et le pire de tout, c'est sans doute la configuration, parce que c'est une ressource qui permet de d�finir comment les autres ressources seront utilis�e
... je pourrais surement trouver un tas d'autres ressources
�videment si tu ne te contrains pas par toi-m�me, tu vas avoir une arm�e de managers :mrgreen: :mrgreen:

> les descriptions d'objets devrant �tre affich�s (les points qui les composent et les vertices qui relient ces point) sont aussi des ressources :
Pourquoi des ressources? :koi: :koi: Ce sont en r�gle g�n�rale des classes avec une logique ultra-ultra r�duite. Tellement r�duite que tu peux faire une classe=une ent�te seulement.

Par exemple: un Point 2D: x, y - un �l�ment dans une liste plate (listview par exemple): texte ID - un utilisateur: ID, nom, pr�nom, soci�t�.

> une base de donn�e, pareil
C'est ce que j'appelle des "App Datas"

Pour moi, il y a 2 types de "App Datas"
1. Beaucoup d'attributs, quasi aucune logique. Un "gros panier" (tr�s souvent en lecture seule) qu'on passe d'un objet � un autre.
2. Tr�s peu d'attributs, mais beaucoup de logique. Par exemple: une base de donn�e. Tu vas avoir 2-3 "handles" et � c�t� toutes tes requ�tes SQL (et �ventuellement des proc�dures stock�es et des triggers).
Et si j'ai un gros fichier .cpp, en C/ C++ on peut casser ce gros fichier en plusieurs :mrgreen: (il faut juste un include de ton fichier .h dans chacun) afin de faire une r�partition logique de ses m�thodes.

> Et le pire de tout, c'est sans doute la configuration
Pour moi, la configuration ce sont 2 m�thodes load/ save + une structure :mrgreen:
M�me une configuration comme Apache je ne pense pas que ce soit diff�rent.

Et comme tu ne sauvegardes pas ta configuration souvent, ta grosse classe(*) peut la g�rer toute seule.
Surtout que la configuration est charg�e au lancement.
Et au passage, tu n'as pas de Configuration Manager en m�moire pour rien.

Citation:

Envoy� par koala01

Et le r�sultat ne se fera pas attendre : tu te retrouveras tr�s rapidement avec trois, cinq ou dix endroits o� "quelqu'un" d�cide de charger ou de cr�er une texture.

C'est s�r que si tu fais un manager sans r�fl�chir cela va �tre compliqu� par la suite :mrgreen:

Pour moi un manager c'est une "classe d�l�gu�e" vers des objets concrets qu'il contient. Une sorte de proxy, interface, ou patron de conception du m�me style.

Mais, ce que je fais, (<- Un gros mais), ton manager expose que des m�thodes classiques et/ ou "en lecture seule".

Pour un Texture Manager: get_texture/ list_textures.
Pour un Sound Manager: get_sound/ list_sounds.

Ainsi, tu peux facilement �changer les classes concr�tes: MP3_Sound_Manager, WAV_Sound_Manager.

Et � c�t� de cela, pr�voir un syst�me via ton Manager (***) pour r�cup�rer un objet concret et avoir une interface sp�cifique �tendue:
MP3_Sound_Manager::create_sound(), JPG_Texture_Manager::set_compression_level(), ...

D'ailleurs, je ne pense pas que ces m�thodes sp�cifiques soient utiles partout :mrgreen: :mrgreen:. Juste � des endroits pr�cis.

Toujours le m�me principe :whistle:: cela ne me d�range pas que ma classe Manager soit utilis�e � pleins d'endroits.
Parce que 0) c'est un peu son r�le (comme un frigo dans une cuisine) 1) j'ai contrains un grand nombre de ses m�thodes en lecture seule 2) effet "bottle neck" avec un point d'arr�t dans le manager 3) avec une recherche, je trouve toutes les occurrences

** -> si c'est possible par exemple un bouton qui s'adapte � la taille de son texte, ou un algo de rendu.
*** -> par exemple: private + friend

Citation:

Envoy� par foetus

Je ne suis pas d'accord :mrgreen:

Lorsque je parle de "god object" (peut-�tre � tord) c'est l'objet principal que certaines biblioth�ques (surtout IHM comme Qt, VCL) ont besoin pour lancer l'application (et initialiser la fen�tre principale).
Et je ne parle pas d'h�ritage, polymorphisme, h�ritage multiple, ou autre ... juste de l'utilisation de cette classe principale (*).

Ah, ben oui, tu as effectivement une classe (QApplication, dans le cas de Qt) qui va mettre tout le syst�me en branle et s'assurer que tout sera correctement initialis�. Ce n'est pas une raison (et c'est l'un des reproche que je fais � Qt) pour connaitre cette classe pour pouvoir acc�der aux diff�rents services quelle regroupe. D'autant plus que les services en question sont TOUS mod�lis�s sous la forme d'une classe sp�cifique.

Ceci dit, le domaine de l'IHM est -- justement -- le contre exemple flagrant de ce qu'il faut faire � bien des �gards ;)

Citation:

Donc je trouve "�trange" que pour respecter les principes SOLID SRP OCP ou autres, on ne doit pas profiter de cette grosse classe (et de sa commodit�).
Surtout qu'un de ses r�les c'est l'initialisation au lancement (entre autres comme thread d'affichage ou les gros traits/ lignes de la logique IHM)

Oui, bien sur : il est important de veiller � ce que tout ce qui doit �tre initialis� pour fournir les services que l'on attend de la part d'une IHM soit initialis� de mani�re simple (ex, comme c'est le cas de Qt, en ayant une classe sp�cifique dont l'instanciation s'occupera de cr�er tous les �l�ments n�cessaires pour rendre ces services)

Citation:

Les managers sont d'ailleurs essentiellement initialis�s au d�marrage.

(je passe sur le probl�me qu'il peut y avoir � parler de "managers" ou de "gestionnaires"... je reviendrai dessus � la fin de mon intervention ;) )
Oui, et alors :question: Qu'est ce qui t'emp�che d'avoir une classe proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 class MaClasseEntreeApplication{ /* ... */ private: /* juste au cas où on voudrait l'instancier deux fois */ static bool alreadyCreated_; ThreadStack threads_; EventHandlerCollection events_; /* ... */ }; /* pour ne pas devoir passer par MaClasseEntreeApplication */ EventHanderlCollection & events(){ /* peu importe comment on le récupère */ } ThreadStack threads(){ /* peu importe comment on le récupère */ } .... someStuffWeWantToGet() { /* ... */ }
La loi de D�m�ter dit que, si un objet de type A manipule en interne un objet de type B, l'utilisateur du type A ne doit pas avoir connaissance du type B pour manipuler son objet de type A.

Mais il ne faut pas non (et encore moins) plus obliger l'utilisateur du type B � connaitre le type A pour pouvoir acc�der � son type B.

La plupart des biblioth�ques d'IHM sont apparues � une �poque o�

la philosophie �tait proche du "tout objet" (comprend : fonctions membres uniquement), en ignorant volontairement les possibilit�s multi paradigme du C++
l'approche du paradigme orient� objet �tait encore bien plus orient�e sur les donn�es manipul�es que sur les services rendus par les diff�rentes fonctionnalit�s (il suffit de voir le nombre de mutateurs pour s'en convaincre)

Alors, bien sur, dans un tel contexte, il devient sans doute impossible de se passer de la notion de singleton. Mais, si tu accepte l'id�e de cr�er des fonctions libres et que tu commences r�ellement � penser en termes de services et non en termes de donn�es manipul�es, tu te rendras compte qu'il n'y a rien qui soit fournit par ton singleton qui doive effectivement �tre disponible strictement partout et que, si tu as besoin de certaines fonctionnalit�s propos�es par ton singleton � plusieurs endroits, tu n'as absolument aucun besoin de pouvoir acc�der � l'ensemble de ces fonctionnalit�s.

D�s lors, si tu s�pare l'ensemble des fonctionnalit�s propos�es par ton singleton en autant de fonctionnalit�s distinctes et ind�pendantes, tu gagne la libert� de ne fournir que ce dont tu as r�ellement besoin � chaque moment et, surtout, tu gagne � ne pas �tre tent� de rajouter une d�pendance dont tu aurais pu te passer.

Citation:

Et lorsque tu parles de MVC, je voulais te faire remarquer que cette grosse classe peut faire office de contr�leur et ton manager de mod�le.
Apr�s, pour diff�rentes raisons (temps de d�marrage, maintenance, �volution...), tu peux le faire �voluer en un vrai MVC.

La question que je te poserai � ce sujet est : pourquoi attendre pour d�cider d'utiliser quelque chose dont tu as la garantie que tu devra de toutes mani�res y avoir recours :question:

Il sera beaucoup plus facile pour toi de mettre directement un MVC correct en route que de commencer en regroupant les fonctionnalit�s propres au(x) contr�leur(s) et celles propres au(x diff�rents) mo�le(s) et de devoir s�parer le tout "apr�s coup" parce que tu te rend compte que cela devient ing�rable ;)

Citation:

J'ai d� mal � voir un projet/ application avec lequel/ laquelle toutes les classes ont tr�s peu de d�pendances :whistle:
D�j� la classe principale (*) est un contre-exemple.

Ou alors un petit projet, une petite application.

Tu n'as alors jamais vu les projets sur lesquels j'ai travaill�...

Certains �taient de tr�s gros projets, et on limitait pourtant les d�pendances au stricte minimum. Et il y a parfaitement moyen de le faire ;)

Citation:

Parce que c'est bien joli d'avoir une arm�e de classes � 1 responsabilit�, de pouvoir les tester individuellement (**), etc..., mais apr�s il faut mettre en place tout le ciment pour cr�er/ d�truire et aussi passer le bon objet. Sans parler de ton projet qui explose en terme de classes/ fichiers.

Le ciment � mettre en place pour g�rer cette armada de petite classe est beaucoup plus simple que celui n�cessaire pour �viter de faire tomber tout un tas de classes monolithiques, je peux te l'assurer ;)

Citation:

Ton exemple de classes: TextureFactory, TextureLoader, TextureHolder, SoundFactory, SoundLoader, SoundHolder, ... cela fait un peu peur :? :?

Pourquoi est ce qu'il te fait peur :question:

Citation:

Une mise en situation: tu codes un jeu et tu dois prendre en compte 3 types de textures (png, DXT je-ne-sais-pas-quoi, et autre chose) et 2 types de sons.

Au lieu d'avoir 5 grosses classes + 1 manager "classe d�l�gu�e" (mais il y a s�rement d'autres fa�ons de coder) (et je signale au passage que si tu cherches un algo par rapport au mp3 ou au png, tu sais exactement o� il est) tu vas avoir (3xX + 2xY) classes.

Sans parler du fait que rien pour g�rer tout cela tu vas mettre en place de l'h�ritage (certes simpliste), mais un h�ritage quand m�me. Donc (3xX + X + 2xY + Y) classes

J'aurais surement un nombre de classes plus grand que 1 ou 2, ca je te l'accorde mais :

1 - Tr�s peu d'h�ritage:

peut �tre pour faire la distinction entre les textures "donn�es" (issues de formats comme png ou jpeg) est les textures "fonctionnelles",
peut �tre pour faire pareil au niveau de Sound (mais aucun lien entre Sound et Texture);
Peut-�tre, au niveau des loader permettant de charger diff�rents formats de textures ou diff�rents formats de sons (mais, encore une fois, sans liens entre les SoundLoader et les TextureLoader, autres que leur interface, peut �tre)

2- J'aurais, effectivement, une TextureFactory et une SoundFactory qui me permettraient respectivement de "centraliser" la connaissances des diff�rents types d�riv�s, ce qui me permettrait de n'avoir pas besoin de savoir autre chose que le fait que je manipule une texture ou un son partout ailleurs
3- j'aurais effectivement un TextureHolder et un SoundHolder, qui se contenteraient de maintenir les textures (respectivement les sons) en m�moire "tant qu'ils sont utilis�s"

Citation:

Je pr�vois d�j� que tu vas me r�pondre que ton IDE c'est le plus puissant de la terre (VIM, Visual, ...)

A vrai dire, � titre perso, je code g�n�ralement avec un truc aussi simple que gedit (notepad++) et en utilisant les autotools sous linux... On peut trouver assez facilement des solutions "plus puissantes" pour faire le travail ;)

Et pourtant, le nombre de fichiers / de classes ne me fait absolument pas peur ;). Par contre, ce qui m'�nerve � chaque fois, c'est de voir une s�rie de tests unitaires planter parce que j'ai eu "le malheur" de vouloir int�grer une �volution � mon projet ;)

Citation:

que tu t'en fiches tu g�res X projets en m�me temps (donc tu n'es pas � quelques classes en plus)

J'ai effectivement, plusieurs projets perso en cours...

Mais ce n'est pas pour cela que je ne suis pas � "quelques classes de plus"... Si je ne suis pas � "quelque classes de plus", c'est parce que j'ai eu tr�s largement l'occasion de me rendre compte de tous le b�n�fice que l'on peut tirer � effectivement s�parer clairement les diff�rentes fonctionnalit�s ;)

Citation:

et que je n'ai jamais cod� sur/ maintenu un gros projet monolithique.

Je ne te connais pas assez pour dire cela ;)

Citation:

Et je peux rajouter que je code que des applications pas des biblioth�ques mais avec de la conception pour reprendre et r�utiliser "une colonne vert�brale".

Et, si je ne veux r�cup�rer qu'une vert�bre :question: je fais comment :question: je prend toute la colonne vert�brale, ou j'arrive � ne prendre que L4 sans trop me casser la t�te :question:

Citation:

�videment si tu ne te contrains pas par toi-m�me, tu vas avoir une arm�e de managers :mrgreen: :mrgreen:

On arrive bientot au bout... les explications vont venir ;)

Citation:

> les descriptions d'objets devrant �tre affich�s (les points qui les composent et les vertices qui relient ces point) sont aussi des ressources :
Pourquoi des ressources? :koi: :koi: Ce sont en r�gle g�n�rale des classes avec une logique ultra-ultra r�duite. Tellement r�duite que tu peux faire une classe=une ent�te seulement.

Je voulais parler des donn�es destin�es � �tre envoy�es � OpenGL que tu r�cup�res en lisant un fichier .obj ou 3ds ;)

Citation:

Par exemple: un Point 2D: x, y - un �l�ment dans une liste plate (listview par exemple): texte ID - un utilisateur: ID, nom, pr�nom, soci�t�.

> une base de donn�e, pareil
C'est ce que j'appelle des "App Datas"

Pour moi, il y a 2 types de "App Datas"

Beaucoup d'attributs, quasi aucune logique. Un "gros panier" (tr�s souvent en lecture seule) qu'on passe d'un objet � un autre.
Tr�s peu d'attributs, mais beaucoup de logique. Par exemple: une base de donn�e. Tu vas avoir 2-3 "handles" et � c�t� toutes tes requ�tes SQL (et �ventuellement des proc�dures stock�es et des triggers).

Tout d�pend de la d�finition que tu fais du terme "ressources".

Le vrai probl�me, c'est que m�me si tu te limite aux seules "ressources informatiques" (en g�n�rale), la d�finition de ce terme est proche (selon wikipedia) de

Citation:

Envoy� par wikipedia

En informatique, les ressources sont des composants, mat�riels ou logiciels, connect�s � un ordinateur. Tout composant de syst�me interne est une ressource. Les ressources d'un syst�me virtuel incluent les fichiers, les connexions au r�seau, et les zones de m�moire.

En cela, ce que tu appelle App Datas ne sont rien d'autre que... des ressources ;)

Citation:

> Et le pire de tout, c'est sans doute la configuration
Pour moi, la configuration ce sont 2 m�thodes load/ save + une structure :mrgreen:
M�me une configuration comme Apache je ne pense pas que ce soit diff�rent.

Non, les fonctions load et save ne sont que les parties visibles de l'iceberg...

La partie non visible, c'est que, m�me s'il ne s'agit que d'une structure "POD", c'est bel et bien une ressource (quelque chose qui utilise de la m�moire) et qui utilis� quasiment partout dans le code, parce que l'on y m�lange all�grement les donn�es de configuration de tout et de n'importe quoi (ex : taille et r�solution d'affichage, volumes sonores divers, adresses des serveurs � contacter, nom d'utilisateur, ...)

Citation:

Et comme tu ne sauvegardes pas ta configuration souvent, ta grosse classe(*) peut la g�rer toute seule.

Je ne dis pas que la classe qui sert de point d'entr�e de l'application ne doit pas g�rer ta configuration d'une mani�re ou d'une autre; je dis:

que tu ne devrais pas avoir besoin de passer par ta classe "point d'entr�e de l'applicaiton" pour acc�der � la configuration
que tu n'a jamais besoin de toutes les donn�es que la configuration met � ta disposition :

si tu est dans un contexte d'affichage, c'est la taille et la r�solution de l'�cran qui t'int�ressent;
si tu est dans un contexte de requ�te SQL / connexion � un serveur, ce sont les adresses du serveur, le nom d'utilisateur,... qui t'int�ressent;
si tu es dans un contexte sonore, ce sont les volumes sonores qui t'int�ressent
...

Citation:

Surtout que la configuration est charg�e au lancement.

Oui, elle sera sans doute charg�e au lancement de l'application et sauvegard�e (si modifi�e) � la fermeture de l'application.

Citation:

Et au passage, tu n'as pas de Configuration Manager en m�moire pour rien.

Ben, je dis justement qu'on n'en a pas besoin... En tout sous la forme d'un "gestionnaire de configuration", et surtout pas si cela sous entend de maintenir la configuration des diff�rents "modules" de notre application "m�lang�s" au sein d'une seule structure.

Je suis tout � fait d'accord pour dire qu'il doit "forc�ment" y avoir un endroit o� l'on regroupera toutes les configurations de tous les modules (ne serait-ce que parce que la configuration de tous les modules peut se retrouver dans un seul et unique fichier de configuration).

Mais on n'a absolument aucun besoin de savoir comment sont trait�s les sons quand on essaye de se connecter � un serveur distant!

[/QUOTE]
C'est s�r que si tu fais un manager sans r�fl�chir cela va �tre compliqu� par la suite :mrgreen:

Pour moi un manager c'est une "classe d�l�gu�e" vers des objets concrets qu'il contient. Une sorte de proxy, interface, ou patron de conception du m�me style.

Mais, ce que je fais, (<- Un gros mais), ton manager expose que des m�thodes classiques et/ ou "en lecture seule".

Pour un Texture Manager: get_texture/ list_textures.
Pour un Sound Manager: get_sound/ list_sounds.

Ainsi, tu peux facilement �changer les classes concr�tes: MP3_Sound_Manager, WAV_Sound_Manager.
[/QUOTE]Que le son soit au format mp3, au format wav ou au format whatTheFuck, tu t'en fous royalement... tout ce qui t'importe, c'est de pouvoir le jouer ;)

Et c'est justement parce que tu esp�re pouvoir profiter des comportements polymorphes pour tes sons ou tes textures (text.drawIt(context); pour une texture; sound.playIt(context); pour un son) qu'il est important de limiter la tentation de l'utilisateur de "celui qui r�cup�re une texture / un son" de chercher � savoir "quel en est le type r�el".

Et c'est pour cela qu'il est important de s�parer clairement les diff�rentes responsabilit�s (qui cr�e la texture ou le son, qui la/le charge, qui la/le maintient en m�moire), de mani�re � ce que l'utilisateur puisse recevoir une "r�f�rence" (qui sera en r�alit� un pointeur ou une r�f�rence C++) sur "une texture" ou sur "un son" et pour qu'il puisse savoir qu'il "doit faire avec", sans essayer de r�cup�rer le "type r�el" de sa texture ou de son son.

Citation:

Et � c�t� de cela, pr�voir un syst�me via ton Manager (***) pour r�cup�rer un objet concret et avoir une interface sp�cifique �tendue:
MP3_Sound_Manager::create_sound(), JPG_Texture_Manager::set_compression_level(), ...

Mais ca, c'est pas le gestionnaire qui doit s'en occuper...
la cr�ation d'un son est un m�canisme dont l'utilisateur n'a absolument rien � foutre et qui devrait �tre d�l�gu� � une fabrique (qui se d�charge d'une partie du travail sur diff�rents Loaders) et r�glage du niveau de compression JPEG, ca se g�re exclusivement au niveau de la s�rialisation (chargement /sauvegarde) du fichier.

Alors, que tu aies une fonction add(filename) qui passe par la fabrique pour ajouter une texture ou un son (selon ce que tu manipules) est tout � fait coh�rent, mais l'utilisateur de ce qui devient un TextureHolder ou un SoundHolder (une classe qui se contente de fournir les services relatifs au maintient des sons/des textures en m�moire) n'a absolument pas besoin de savoir comment le son / la texture ajout�e a �t� cr��e (et au paravant charg�e).

Citation:

D'ailleurs, je ne pense pas que ces m�thodes sp�cifiques soient utiles partout :mrgreen: :mrgreen:. Juste � des endroits pr�cis.

Raison de plus pour ne pas les rendre accessibles partout parce que disponibles dans l'interface d'une classe qui, par nature, risque de se retrouver "n'importe o�"...

Citation:

Toujours le m�me principe :whistle:: cela ne me d�range pas que ma classe Manager soit utilis�e � pleins d'endroits.
Parce que 0) c'est un peu son r�le (comme un frigo dans une cuisine) 1) j'ai contrains un grand nombre de ses m�thodes en lecture seule 2) effet "bottle neck" avec un point d'arr�t dans le manager 3) avec une recherche, je trouve toutes les occurrences

Tu obtiens exactement le m�me r�sultat mais en mieux en s�parant ton manager "monolithique" en diff�rentes classes aux responsabilit�s restreintes car:
C'est le role d'un TextureHolder de maintenir les textures en m�moire tant que tu en as besoin (mais c'est aussi celui d'un SoundHolder, sauf que tu n'auras que des sons ou des textures ;), un peu comme un frigo dans une cuisine
tu mes un points d'arr�t sur un TextureHolder et tu es sur que chaque fois que tu passe sur ce point d'arr�t, c'est parce que tu manipule une texture. M�me chose pour les sons et ton SoundHolder, et pour n'importe quel autre type de ressource
la recherche de ton instance de TextureHolder ou de ton instance de SoundHolder est beaucoup plus pr�cise que celle de ton Manager car tu n'en a rien � foutre des circonstances dans lesquelles tu manipules un son si tu cherche celles o� tu manipule une texture (et vice versa)

D�sol�, pour finir, je ferai mon spitch sur les "manager" demain ;)