Alors, dans l'ordre :
Pour la méthodologie, je trouvais intéressant de montrer en application comment se servir de ces méthodes magiques.
Dans mon projet, j'ai utilisé ce système car je n'aime pas, comme dit plus haut, devoir utiliser les singleton (bien que ça en soit presque un). Et surtout, j'apprends. Alors pourquoi pas essayer de l'expliquer à d'autres.
Et dans un cas plus général, il ne faut pas s'arrêter au tuto (mais peut-être que j'aurai dû en parler) :
Dans mon exemple, J'utilise ce système pour 2 raisons :
- Comme dit, pas de get_instance, il est partout.
- Surtout, les attributs de ma CurrTown sont publics. Donc je peux les lire depuis mes vues etc, mais si je veux, je peux enlever la possibilité à tout autre classe de modifier mon CurrTown. Il me suffit pour cela de retirer mon 'Setter magique'.
Et il y a bien d'autres cas à pouvoir utiliser ce système.
Pour la forme, je prends note. C'est vrai que je ne savais pas trop comment me lancer, et mon esprit a dû rester hésitant
Sinon, pourquoi je ne recopie pas mes attributs dans ma classe :
Il s'agit de colonnes présentes dans ma DB et qui sont suceptibles d'évoluer. De plus, certains attributs seront dynamiques, toujours.
Par exemple pour mes ressources (plusieurs dizaines différentes), elles sont stockées dans une autre table et non dans Towns. Elles évolueront au fil du jeu, et je n'ai pas envie de copier/coller plus de 50 attributs juste pour mon IDE, et de devoir mettre à jour ma classe à chaque MAJ du jeu.
Faire du dynamique, c'est pour moi un des avantages de la POO.
niahoo : Mon code s'approche involontairement de plus en plus à ce pattern. Par exemple, mes controllers ne travaillent pas avec mes models directement :
Ils passent par une classe qui fait le boulot plus complexe, pour avoir un code utilisateur (dans le controller) le plus facile à comprendre possible.
C'est de l'abstraction en plus, sûrement plus dur à maintenir mais j'adore ce concept.
Concernant Laravel, je ne le connais pas du tout.
Enfin, j'instancie CurrTown dans la classe Mere de mes controllers.
Donc à chaque controller qui est instanciée, celui-ci lance l'Init() selon si le joueur a choisi sa cité ou pas (en session).
Voilà en gros le code épuré :
Pour la méthodologie, je trouvais intéressant de montrer en application comment se servir de ces méthodes magiques.
Dans mon projet, j'ai utilisé ce système car je n'aime pas, comme dit plus haut, devoir utiliser les singleton (bien que ça en soit presque un). Et surtout, j'apprends. Alors pourquoi pas essayer de l'expliquer à d'autres.
Et dans un cas plus général, il ne faut pas s'arrêter au tuto (mais peut-être que j'aurai dû en parler) :
Dans mon exemple, J'utilise ce système pour 2 raisons :
- Comme dit, pas de get_instance, il est partout.
- Surtout, les attributs de ma CurrTown sont publics. Donc je peux les lire depuis mes vues etc, mais si je veux, je peux enlever la possibilité à tout autre classe de modifier mon CurrTown. Il me suffit pour cela de retirer mon 'Setter magique'.
Et il y a bien d'autres cas à pouvoir utiliser ce système.
Pour la forme, je prends note. C'est vrai que je ne savais pas trop comment me lancer, et mon esprit a dû rester hésitant
Sinon, pourquoi je ne recopie pas mes attributs dans ma classe :
Il s'agit de colonnes présentes dans ma DB et qui sont suceptibles d'évoluer. De plus, certains attributs seront dynamiques, toujours.
Par exemple pour mes ressources (plusieurs dizaines différentes), elles sont stockées dans une autre table et non dans Towns. Elles évolueront au fil du jeu, et je n'ai pas envie de copier/coller plus de 50 attributs juste pour mon IDE, et de devoir mettre à jour ma classe à chaque MAJ du jeu.
Faire du dynamique, c'est pour moi un des avantages de la POO.
niahoo : Mon code s'approche involontairement de plus en plus à ce pattern. Par exemple, mes controllers ne travaillent pas avec mes models directement :
Ils passent par une classe qui fait le boulot plus complexe, pour avoir un code utilisateur (dans le controller) le plus facile à comprendre possible.
C'est de l'abstraction en plus, sûrement plus dur à maintenir mais j'adore ce concept.
Concernant Laravel, je ne le connais pas du tout.
Enfin, j'instancie CurrTown dans la classe Mere de mes controllers.
Donc à chaque controller qui est instanciée, celui-ci lance l'Init() selon si le joueur a choisi sa cité ou pas (en session).
Voilà en gros le code épuré :
Code PHP :
<?php
// Classe Mere
class MY_Controller
{
function __construct()
{
// Utilisateur non connecté
if (!CurrUser::$IsLoggedIn || !CurrUser::$server)
{
// Si URL non accessible au public, on le redirige vers l'accueil
if ($this->uri->segment(1) != 'home' && $this->uri->segment(1) != false)
{
redirect (site_url());
}
// Chargement auto des models
$this->load_Home_Models();
}
else
{
// Utilisateur connecté
$this->load_Game_Models();
if ($this->session->town_id)
{
// Le joueur a déjà choisi sa cité
$town = new Town($this->session->town_id);
CurrTown::Init($town); // <----------------------------------- Ici !
}
}
}
}
// Mon controller
class Game extends MY_Controller
{
function __construct()
{
parent::__construct();
}
function index()
{
var_dump(CurrTown::gold());
}
}
Edit : Désolé l'indentation ne rend pas génial.
Merci de vos commentaires