Salut Oxman :-)
L'utilité ressort uniquement (surtout) sur des jeux ou il y a des quantités importantes de données brutes.
Comme avec les modèles BDD, il y a des méthodes qui travaillent sur ces données dont tu as besoin de façon répétitive sur plusieurs pages. Avec ce "système", tu as tout ce dont tu as besoin: Un singleton (j'imagine que ta connexion BDD est également un singleton...), et des méthodes séparés pour chaque fichier (tables...), le tout en faisant uniquement un extend d'une classe mère qui suit des directives solides en étant abstrait et avec les "finals". Avant PHP 5.3 tu aurait du définir dans chaque classe fille un propre singleton (duplication de code, bwerk).
Avec ce system (le late static binding), tu peux étendre les singletons, ce qui n'était pas "vraiment" possible avant.
Après c'est sur que si toi tu n'as jamais eu le besoin d'avoir des méthodes précise qui travaillent sur tes données brutes de config, ce system est complétement inutile.
Je vais te donner un autre exemple tout simple pour te montrer l'utilité dans mon cas.
Je mets la source PHP et non JSON (plus lisible)
L'utilité ressort uniquement (surtout) sur des jeux ou il y a des quantités importantes de données brutes.
Comme avec les modèles BDD, il y a des méthodes qui travaillent sur ces données dont tu as besoin de façon répétitive sur plusieurs pages. Avec ce "système", tu as tout ce dont tu as besoin: Un singleton (j'imagine que ta connexion BDD est également un singleton...), et des méthodes séparés pour chaque fichier (tables...), le tout en faisant uniquement un extend d'une classe mère qui suit des directives solides en étant abstrait et avec les "finals". Avant PHP 5.3 tu aurait du définir dans chaque classe fille un propre singleton (duplication de code, bwerk).
Avec ce system (le late static binding), tu peux étendre les singletons, ce qui n'était pas "vraiment" possible avant.
Après c'est sur que si toi tu n'as jamais eu le besoin d'avoir des méthodes précise qui travaillent sur tes données brutes de config, ce system est complétement inutile.
Je vais te donner un autre exemple tout simple pour te montrer l'utilité dans mon cas.
Je mets la source PHP et non JSON (plus lisible)
Code PHP :
<?php
$array['material'][0] = 'gold';
$array['material'][1] = 'wood';
$array['material'][2] = 'stones';
$array['material'][3] = 'iron';
$array['food'][0] = 'fruits';
$array['food'][1] = 'rice';
$array['food'][2] = 'bread';
$array['ingredient'][0] = 'wheat';
$array['ingredient'][1] = 'hop';
$array['ingredient'][2] = 'flour';
$array['luxury'][0] = 'beer';
$array['luxury'][1] = 'tobacco';
$array['luxury'][2] = 'liquor';
return $array;
Comme tu le vois, si je récupère mon fichier json, j'ai un array à 2 dimensions.
60 fois (je dis au bol) dans les codes de mon jeu j'ai besoin de cette array tel quel, et 60 fois je veux uniquement la 2ème dimension (je veux donc un array avec uniquement les ressources même, sans les catégories).
ça ne serait pas très pro de faire 60 fois une magouille qui me renvoie mon tableau comme souhaité... C'est la que j'ai besoin d'une fonction qui le fait. Et comme je ne veux pas mettre mes fonctions n'importe ou (et que si en plus je peux hériter de pleins de bonne choses) j'ai donc créer ce systeme.
De plus, le jour ou tu décide de ne plus utiliser JSON, mais autre chose (XML ou je ne sais quoi), tu change uniquement Gamgeconfig.php sans te soucier de tout le reste... ton application vas fonctionner pareillement! Ou encore, tu utilise plusieurs formats... Il suffit de créer des lecteurs dans la classe Gameconfig.php, tout le reste n'est pas touché! Voilà en gros
En me relisant je ne suis pas vraiment sur d'avoir été beaucoup plus clair... Bonne chance pour me déchiffrer ^^