Passage d'un développement PHP vers de la POO

Bonjour,

J'essaye depuis plusieurs mois de me débrouiller mais j'ai des problèmes "ethiques" quand au redeveloppement d'une appli PHP vers de la POO.

Mon dev est entre le framework et le CMS, il a été développé il ya 10 ans en PHP et a bien muri. je le passe depuis quelque smois en POO, je n'utilise qu'un niveau faible de POO : pas d'interface, pas d'heritage (quoi que là ca va peut etre venir) etc etc bref le basic du basic de l'utilisation des classes.

Mon problème principal est le suivant :
j'ai une couche de traitement d'affichage et de récupération d'environnement (recup des GET, POST, SESSION, etc)

Ensuite selon les besoins j'appel mes modules qui sont des classes, soit en appelant une fonction générale à toutes mes classes pour demander un retour de données, soit en appelant une fonction précise que je connais par l'environnement (un hidden dans un formulaire par exemple)

Le soucis principal est que tout mon environnement d'avant l'appel de ma fonction dans une classe, qui est instanciée pour l'occasion, n'est pas accessible par cette instanciation. quelle solution ? je peux passer des parametres ? un pointeur de l'instanciation d'une classe qui gere l'environnement ? je vais quand meme pas re faire une instanciation qui va re-generer toutes mes données d'environnement, si ?

je sais pas si j'ai été tres clair....

Selon vos questions ou résponses eventuelles j'essayerai de re-expliquer ca autrement, promis...

j'espere que vous pourrez m'aider et me faire avancer dans la comprehension des structures objets !

pour gérer tout ce qui est données utilisateurs (session, get, post), je te
conseille de faire des singletons déclarés en amont bien sûr, en global afin d'en
disposer dans toutes tes classes.

je ne sais pas si çà répond à ton problème car je ne l'ai pas encore bien saisi :p

Citation:

---

Envoyé par bricecol

pour gérer tout ce qui est données utilisateurs (session, get, post), je te
conseille de faire des singletons déclarés en amont bien sûr, en global afin d'en
disposer dans toutes tes classes.

je ne sais pas si çà répond à ton problème car je ne l'ai pas encore bien saisi :p

---

Si, c'est déjà un bon début de réponse !

Plutot que des variables qu'on ajoute en global, on peut pas mettre une instanciation d'une classe spécialisée dans le straitements et qu'on recup en gloabl dans chaque classe pour pouvoir toujours l'appeler en gardant ses contenus précédents ?

Citation:

---

Envoyé par Punky65

Plutot que des variables qu'on ajoute en global, on peut pas mettre une instanciation d'une classe spécialisée dans le straitements et qu'on recup en gloabl dans chaque classe pour pouvoir toujours l'appeler en gardant ses contenus précédents ?

---

Les singletons servent à ça. Pouvoir récupérer un objet d'où que l'on soit dans l'app et dont on sait qu'il sera toujours unique.
Trop de singletons, c'est jamais bon. Ca cache souvent un mauvais design. Après tout, les singletons ne sont ni plus ni moins que des "variables globales". Et en POO, on fuit les variables globales comme la peste. Il y a donc une contradiction.

A part ça, je ne sais pas si tu as saisi un truc important (peut être que je me trompe à ton sujet) : que l'on utilise des classes, fonctions ou n'importe quoi d'autre, tout l'environnement de php est détruit et réinitialisé à zero à chaque requête. Il n'y a pas de persistance native des objets de requêtes en requêtes. Il faut se débrouiller avec cette contrainte (qui peut être vu comme un avantage d'ailleurs).

Citation:

---

Envoyé par Punky65

Si, c'est déjà un bon début de réponse !

Plutot que des variables qu'on ajoute en global, on peut pas mettre une instanciation d'une classe spécialisée dans le straitements et qu'on recup en gloabl dans chaque classe pour pouvoir toujours l'appeler en gardant ses contenus précédents ?

---

c'est le principe du singleton de ne pas utiliser de variables globales
et comme ça dans chaque classe tu fais ça pour l'utiliser :

Code:

---

1 2	$configuration = Configuration::obtientSingelton(); $valeur = $configuration->obtient('valeur');

---

Ok j'ai compris pour les singleton, c'est donc exactement là ou j'en venais en fait.

Pour le fonctionnement PHP et session oui pas de soucis, je connais ca je bosse en PHP depuis 9 ans et en ASP depuis... que ca existe (mais plus depuis 9 ans)

Pas simple de passe un dev PHP en POO meme s'il a été concu tres modulaire et a été tres "factorisé" .

Mon soucis suivant est l'héritage, j'ai du mal à saisir dans mon dev si mes classes de modules doivent hériter d'une classe autre ou appeler des fonctions exterieures.

Actuellement en gros j'ai 2 includes de fonctions, l'un avec des trucs un peu standards de boite à outils : travail de chaine pour les acecnts, travail sur les dates etc etc, l'autre qui serait en fait le dernier truc à passer en classe ce sotn les fonctions du "noyeau" de mon Framework/CMS, en général elle commencent toutes betement par CMS_xxx et certaines sont plus des procédures du noyeau d'autres des fonctions accompagnant le noyeau et les modules....

Votre avis sur l'héritage etc etc ?

Citation:

---

Envoyé par metagoto

Les singletons servent à ça. Pouvoir récupérer un objet d'où que l'on soit dans l'app et dont on sait qu'il sera toujours unique.
Trop de singletons, c'est jamais bon. Ca cache souvent un mauvais design. Après tout, les singletons ne sont ni plus ni moins que des "variables globales". Et en POO, on fuit les variables globales comme la peste. Il y a donc une contradiction.

A part ça, je ne sais pas si tu as saisi un truc important (peut être que je me trompe à ton sujet) : que l'on utilise des classes, fonctions ou n'importe quoi d'autre, tout l'environnement de php est détruit et réinitialisé à zero à chaque requête. Il n'y a pas de persistance native des objets de requêtes en requêtes. Il faut se débrouiller avec cette contrainte (qui peut être vu comme un avantage d'ailleurs).

---

En fait je viens de lire un article sur les singletons et c'est aussi la réponse à un autre de mes soucis, j'aimais pas trop avoir des tas de connexions ADODB, et j'avais créé une class CRUD pour gerer mieux mes acecs à mes tables....avec le probleme d'etre instancié par pleins d'autres classes. Là c'est nickel avec le singleton, sans parler de pouvoir gerer d'autres problématiques d'environnement....

Merci pour cet éclairage !

Citation:

---

Envoyé par Punky65

Actuellement en gros j'ai 2 includes de fonctions, l'un avec des trucs un peu standards de boite à outils : travail de chaine pour les acecnts, travail sur les dates etc etc, l'autre qui serait en fait le dernier truc à passer en classe ce sotn les fonctions du "noyeau" de mon Framework/CMS, en général elle commencent toutes betement par CMS_xxx et certaines sont plus des procédures du noyeau d'autres des fonctions accompagnant le noyeau et les modules....

---

les questions d'héritage sont surtout importantes pour tes applications métiers. si par exemple tu dois gérer des voitures et des vélos, il y aura des grandes chances que tu aies une classe mère "véhicule". ainsi si dans quelques années la partie "voiture" se développe, tu pourras rajouter des classes "citadine", "break", etc. qui hériteront de "voiture"
mais pour tes fonctions du framework il n'y aura pas beaucoup de modifications sur la structure, il y a plus de chances d'avoir une fonction à rajouter ou alors une autre fonction à mettre à jour. donc dans ce cas l'héritage n'importe pas beaucoup, choisi plutôt la simplicité d'utilisation.
par exemple ton code sera plus clair comme ça :

Code:

---

$telephoneAffichage = FonctionFramework::formatTelephone($telephone);

---

que ça par exemple

Code:

---

1 2	$gestionnaireFormatage = Formatage::constructionGestionnaire('chaine_de_caractères'); $telephoneAffichage = $gestionnaireFormatage::obtientSingleton()->format('telephone', $telephone);

---

Ok, effectivement la POO est là pour simplifier le code donc autant le faire.

je suis en train de mettre noir sur blanc l'enchainemment des actions sur ma partie qui n'est pas dutout en POO, pour mieux voir comment transformer ça.
j'ai déjà transforer la partie admin qui est 100% POO mais qui du coup va etre surement un peu revue grace au singleton notament, et qui sera utilisée également part lapartie public d'affichage du site.

je viens tester de passer une class en singleton, mais du coup dans ma classe je dois remplacer tous les appels $this-> en self:: ??

Citation:

---

Envoyé par Punky65

je viens tester de passer une class en singleton, mais du coup dans ma classe je dois remplacer tous les appels $this-> en self:: ??

---

Non , singleton ne veut pas dire static.
Tu n'aura que ta methode getInstance() qui sera statique , donc tu peut tout à fait laisser les autre avec $this

Citation:

---

Envoyé par grunk

Non , singleton ne veut pas dire static.
Tu n'aura que ta methode getInstance() qui sera statique , donc tu peut tout à fait laisser les autre avec $this

---

Comme je ne suis plus à une question "stupide" pret, une autre :
Il y a un interet, si c'est possible, de créer une class qui herite d'un singleton ?

en tapant le pourquoi de ma question, je m'appercois que c'est soit inutile soit...bete. mais en théorie c'est faisable ?

C'est faisable et pas forcément bête (à mon avis...) puisque tu vas contenir la logique du singleton dans une seule classe (abstraite) qui sera héritée par tes classes à instance unique. Regarde ici...

L'intérêt est que dès qu'une classe hérite de ce super-singleton, il ne reste plus qu'à définir un constructeur protégé dans ta classe dérivée, et spécifique à cette classe, la classe-mère se charge du reste au niveau de l'instanciation.

Pas besoin de redéfinir les variables statiques où la méthode getInstance, puisqu'elle est la même pour tout singleton.

Hériter d'un singleton n'est possible simplement que depuis PHP 5.3 avec les LSB.

Sinon il faut redéfinir la methode getInstance à cause de la portée de self:: et on perd pas mal de l'intérêt de l'héritage :)

@grunk : il y a une solution intermédiaire, mais j'avoue ce n'est pas ce qu'il y a de mieux...

On récupère le nom de la classe appelante (possible en PHP 5.2, voir le post que j'ai cité précédemment), on stocke l'instance de chaque classe dérivée dans un tableau dans la classe mère (Singleton)... Quand on appelle getInstance depuis la classe dérivée, on appelle véritablement getInstance de la classe mère, qui retourne l'élément du tableau en fonction de la classe appelante....