Discussion :

[Punky65]

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 !

[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

[Punky65]

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 ?

[metagoto]

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).

[Punky65]

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 !

[nosferapti]

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 :

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

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

[Punky65]

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 ?

[nosferapti]

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 :

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

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

que ça par exemple

Code :

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

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