Méthodes magiques, classe statique en instance

[srm]

Bah justement tu as faux.
Si tu le mets dans ton super contrôleur alors c'est lui que le passe toujours à ton template et tu y as toujours accès.
Et ça ne te simplifie pas le dev vu ce que tu as du dev au premier post.

[niahoo]

Ben non, s'il utilise une façade il y a toujours accès de façon globale sans justement avoir à le passer. CommeCa::coucou().

[srm]

Et donc qu'une donnée tombe du ciel dans la vue pas de soucis ?

[niahoo]

Ben c'est juste une dépendance qui a été injectée automagiquement via les méthodes ... magiques. Je vois pas où est le problème.

[Max72]

Non c'est vrai que sémantiquement, mon template ne devrait pas avoir accès direct à mon objet CurrTown.
Mais comme déjà dit, ça m'évite de passer l'objet depuis chaque controller.

Mais là ça n'a rien à voir avec le code en lui-même, c'est juste une question de bonne/mauvaise pratique.

[Xenos]

On pourrait m'expliquer pourquoi ce CurrTown est mieux qu'une variable globale? Ou qu'une fonction globale (qui utilise une variable globale ou une variable statique)?
Car, là, j'ai pas compris pourquoi tu réinventes ce concept (on disant au passage que cette pratique n'est pas terrible, mais le fait de la "cacher" dans un autre système ne la rend pas meilleure) ?!

Ca me fait un peu penser à ceux qui disent "les iframe, c'est le mal, faut surtout pas les utiliser" et qui utilisent des bibliothèques javascript qui ne font que les réinventer (mal d'ailleurs), à coup de JSON, d'AJAX et de mutation DOM...

[niahoo]

@Xenos

C'est en fait une implémentation du Service Locator Pattern, un mécanisme d'injection de dépendances et d'inversion de contrôle. C'est une très bonne pratique.

Mais en plus, une façade te permet de meilleurs tests unitaires car l'objet représentant le Service Locator n'est pas directement appelé, cela te donne un endroit pour placer tes mocks.

Une variable globale n'est pas protégée car tu peux la redéfinir par exemple. $curTown = null;.

Une fonction globale, en fait c'est exactement ça. Tout simplement, tu n'as qu'à imaginer que CurrTown:: correspond à getCurrTown(). Et le paamayim nekodutayim inclus remplace les parenthèses. Ensuite le choix de l'un ou de l'autre dépend surtout du style.

[Xenos]

D'accord, dans le style Annuage de services donc. Effectivement, la généralisation est intéressante Merci.

[Max72]

Pour tout vous avouer, ce n'était pas le but recherché de ce mini tuto dit alambiqué ^^
Mais la manière de coder (en façade) est en effet celle qui me plait le plus.

Je n'ai pas expliqué plus que ça pourquoi je n'utilisais pas de singleton, j'aurai dû le faire.
Le fait est que j'essaye d'avoir le moins de couplage possible entre mes classes.

Par exemple, j'essaye actuellement ( sur papier) de faire une façade pour mon ORM (qui utilise MYSQLi). Le but est de pouvoir changer d'ORM par la suite sans me retaper tout le code du jeu (pour passer sous PostgreSQL ou autre), pouvoir mettre un mock devant ma BDD, ..

[niahoo]

Le singleton certains le considèrent comme "pas terrible" car il a de fait deux responsabilités : gérer une instance, et le rôle de l'instance elle-même.

Pour ton ORM, pourquoi ne pas tester Doctrine, Eloquent ou encore Redbean ( http://redbeanphp.com/ ) qui est très sympa quand on bosse sans framework, et qui a la particularité très sympathique de créer automatiquement les tables et les champs en fonction de ton code !