Discussion :

[Elendhil]

Dans différents moteurs on voit souvent cette décomposition , j'aimerais savoir pourquoi on ne stock pas la géometrie , les matériaux et les textures dans le même objet ?

[LeGreg]

Dans différents moteurs on voit souvent cette décomposition , j'aimerais savoir pourquoi on ne stock pas la géometrie , les matériaux et les textures dans le même objet ?

Souvent la texture est découplée du matériel (exemple : illumination par pixel est un shader matériel qui peut s'appliquer sur un grand nombre de textures diffuses/normales différentes).
De meme le matériel est découplé du mesh (plusieurs objets dans le monde partage le même matériel mais ont des géométries et textures différentes).

Bien entendu toute segmentation est arbitraire et tu peux te trouver dans une situation ou tu as besoin de ta propre segmentation..

[Invité]

Dans différents moteurs on voit souvent cette décomposition , j'aimerais savoir pourquoi on ne stock pas la géometrie , les matériaux et les textures dans le même objet ?

Pour eviter les duplications aussi, si tu ne garde qu'une seule copie de chaque texture en mémoire, et non une seule par objet, tu y gagne énormément.

Accessoirement, je pense que dans ton histoire de Gestionnaires (qui a priori sont un container + une méthode de load + une Gestion de cache avec referencre counting (mais pas necessairement)) la séparation est faite simplement pour respecter le SRP... Et qu'il n'y a une class de base RessourceManager qui est ensuite spécialisée avec les bons loaders et/ou containers...

[Emmanuel Deloget]

Pour eviter les duplications aussi, si tu ne garde qu'une seule copie de chaque texture en mémoire, et non une seule par objet, tu y gagne énormément.

Accessoirement, je pense que dans ton histoire de Gestionnaires (qui a priori sont un container + une méthode de load + une Gestion de cache avec referencre counting (mais pas necessairement)) la séparation est faite simplement pour respecter le SRP... Et qu'il n'y a une class de base RessourceManager qui est ensuite spécialisée avec les bons loaders et/ou containers...

Le SRP aurait tendance a être plus respecté si ces "managers" étaient décomposés en classes. On le sent dans la description des "fonctions" (responsabilités) : "un container + une méthode de load + une Gestion de cache" : pas très SRP tout ça...

Rationale: DeMarco a définit (Structured Analysis and System Specification, Tom DeMarco, 1979, Yourdon Press Computing Serie) une responsabilité de classe comme étant un raison de changement (ce qui est plus large qu'une fonction). En couplant chargement et gestion de la collection des ressources, on introduit dans une classe deux raisons de changements:
* modification de la méthode de lecture
* modification de la gestion de la collection (avec, par exemple, ajout d'une gestion de cache).
Il est donc plus sage de découpler ces fonctionnalités.

(m'enfin, chacun voit midi à sa porte; moi, je n'aime pas ce concept de manager - diable, je n'aime pas le mot manager lorsqu'on l'applique à une classe : il ne véhicule aucune description de ce que fait la classe - mais loin de moi l'idée de forcer tout le monde à penser comme moi ).

[Invité]

je n'ai visiblement pas assez developper mon histoire de SRP, je parlait d'un systeme de policies. Par exemple le systeme que j'utilise pour faire mes differents caches ressemble a ca au niveau de la creation du type :

Code :

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

1
2
3
4
5
6
7
8
 
class TextureManager 
	: public ResourceManager<Texture, 
	GTLTextureLoader, 
	ResourceHolderStorage<Texture> > 
{
 
}; // class TextureManager

Le tout est defini de maniere generale de maniere a pouvoir utiliser n'importe quel loader et a peu pres n'importe quelle methode pour les stocker.

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
20
21
22
23
24
25
26
27
28
29
30
 
template <typename RESOURCE_TYPE, class LOADING_POLICY, class STORAGE_POLICY, 
typename ID_TYPE = std::string>
class ResourceManager : public LOADING_POLICY, public STORAGE_POLICY {
public:
	typedef ID_TYPE IDType;
 
	/**
        * Load a named resource.
        * @param name filename or other identifier used to load resource.
        */
	typename STORAGE_POLICY::ReturnType load(const IDType& id) {
		if (STORAGE_POLICY::isStored(id)) 
		{
			return STORAGE_POLICY::getStoredResource(id);
		}
		else 
		{
			// load data
			typedef typename LOADING_POLICY::LoadedDataType DataType;
			DataType data = LOADING_POLICY::loadData(id);
 
			// create resource
			RESOURCE_TYPE* res = new RESOURCE_TYPE(data);
 
			// store data and return reference
			return STORAGE_POLICY::store(id, res);
		}        
	}
};

Quand a la denomination Manager, je suis aussi assez contre, mais faute de mot plus precis, j'ai prefere laisser le nom la pluspart du temps utilise pour ce genre de choses.

Bon, le systeme vaut ce qu'il vaut, il est surement foireux sur pas mal de points, mais pour l'instant il ne m'as pas fait faut bond.