Discussion :

[CinePhil]

Bonjour,

Soit un singleton ErrorCollection destiné à collecter les éventuelles erreurs rencontrées entre la requête URI de l'utilisateur et la génération de la page en réponse.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
namespace Application\Controller;
 
class ErrorCollection
{
	/** Instance du singleton */
	private static $instance = null;
 
	/** Liste des erreurs à afficher */
	private $listeErreurs = array();
 
	/**
	 * Constructeur (Singleton instancié par getInstance)
	 * 
	 * @access private
	 * @param string $langue
	 */
	private function __construct($langue = 'fr')
	{
		//$this->setLangue($langue);
 
		// require 'Application/i18n/'.$langue.'err.php'; TODO i18n
	}
 
	public static function getInstance()
	{
		if(is_null(self::$instance))
		{
			self::$instance = new self();
		}
 
		return self::$instance;
	}
 
	/**
	 * Retourne le tableau de la liste des erreurs à afficher
	 * @return array
	 */
	public function getListeErreurs()
	{
		return $this->listeErreurs;
	}
 
	/**
	 * Ajoute une exception à la liste des erreurs à afficher
	 * @param object $erreur
	 */
	public function ajouterErreur(\ErrorException $erreur)
	{
		$this->listeErreurs[] = $erreur;
	}
}
?>

Je fais ensuite appel aux méthodes du singleton de cette manière :

Code :

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

1
2
3
4
		catch (\ErrorException $e)
		{
			ErrorCollection::getInstance()->ajouterErreur($e);
		}

Y a t-il un moyen plus simple d'utiliser une méthode du singleton que de devoir répéter le code ErrorCollection::getInstance() ?

[grunk]

A part renommer getInstance() et ta classe pour quelque chose de plus court, non.

La syntaxe reste celle que tu as utiliser.

Tu peux éventuellement stocker ton instance dans une variable mais c'est tout.

Code :

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

1
2
3
4
$ec = ErrorCollection::getInstance();
$ec->ajouterErreur($e);
...
$ec->ajouterErreur($e);

[andry.aime]

Bonjour,

Abandonne PHP et vient faire du JAVA, il y a d'Annotations que tu peux utiliser facilement .
Blague à part, tu peux utiliser l'injection de dépendance, Symfony l'utilise, il y aussi PHP-DI que tu peux utiliser. En cherchant un peu, j'ai trouvé Flow qui est encore plus poussé avec son AOP (Programmation Orienté Aspect) pour intercepter tes erreurs ou autre chose.

A+.

[rawsrc]

Salut,

je ne vois pas du tout l'utilité d'utiliser un singleton en guise de collecteur d'erreurs.
Un erreur est toujours dynamique, donc elle doit être traitée à l'exécution.
Les erreurs peuvent être très nombreuses et chaque bout de code peut (doit) réagir différemment donc la centralisation rajoute une couche de difficulté qui ne se justifie pas à mes yeux.

[CinePhil]

@rawsrc :
Il s'agit, dans mon cas, de surtout cumuler les erreurs liées à l'application, suite par exemple au contrôle de la saisie d'un formulaire, pour afficher ensuite le paquet d'erreurs relevées par le programme et non pas de faire revenir l'utilisateur plusieurs fois sur le même formulaire en lui donnant les erreurs l'une après l'autre.
Autre cas que j'aurai à traiter : la validation globale qui contrôle la présence obligatoire de certaines données pas nécessaires en cas d'enregistrement partiel.

Mon exemple avec le catch n'était peut-être pas assez probant pour mon cas.

[rawsrc]

Dans ce cas, je t'invite à raisonner différemment :
Crée une classe d'erreur (EECollector) que tu instancieras au besoin et rajoute y deux méthodes :
- public function transferFrom(EECollector $p),
- public function transferTo(EECollector $p),
ainsi tu pourras empiler les erreurs au fur et à mesure qu'elles apparaissent et les gérer dans toute la chaîne de traitement sans avoir à gérer un singleton

[CinePhil]

EECollector ?

pas trouver ça !


Mon idée a été de créer une classe (singleton) de collection d'erreurs applicatives et d'y stocker si nécessaire des objets standard ErrorException. La collection n'est instanciée que si l'application relève une ErrorException.

Ça revient au même que ton idée, non ?

[grunk]

EECollector n'est qu'un nom que rawsrc donne à sa classe.

Ce qu'il veux te faire comprendre c'est que très souvent le singleton est une fausse bonne idée et ce pour plusieurs raisons :

- Tu risque d'introduire du couplage fort entre certaines classes et ton singleton , là ou avec une classe "normale" tu aurais sans doute fait une injection de dépendance.
- Tu introduit une variable globale dans ton programme , ce qu'on aime éviter le plus possible.
- C'est pas vrai en PHP , mais dans un environnement multi threadé comme en C++ ou en JAVA le singleton risque d'induire des problème de concurrence si il n'est pas parfaitement géré.

Il y'a quelques cas ou le singleton est intéressant , mais un gestionnaire d'erreur n'en fait probablement pas partie.

une lecture intéressante sur le sujet : http://geekswithblogs.net/AngelEyes/...-uploaded.aspx

[rawsrc]

Salut,

C'est normal que t'aies rien trouvé sur le net, EECollector est nom de ma classe en charge de gérer les remontées d'erreur au sein de mon framework (Error and Exception Collector).
Dans la classe, tu collectes les simples alertes comme les exceptions.

Code :

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

1
2
public function addAlert($msg, $process = null, $translate = true, $severity = self::SEVERITY_NOTICE);
public function addException(\Exception $err, $process = null);

Le truc c'est qu'une erreur est fondamentalement dynamique.
Tu peux gérer la collection d'erreurs via une classe de type Dieu mais bon, je ne suis pas fan de ce genre de classe pour plein de raisons.

[CinePhil]

OK. Et je la trouve où ta classe ?

[CinePhil]

Ce qu'il veux te faire comprendre c'est que très souvent le singleton est une fausse bonne idée et ce pour plusieurs raisons :

- Tu risque d'introduire du couplage fort entre certaines classes et ton singleton , là ou avec une classe "normale" tu aurais sans doute fait une injection de dépendance.

Je ne vois pas en quoi c'est problématique avec un singleton, justement ! Le singleton étant instancié par définition une seule fois, c'est juste un objet que j'utilise si nécessaire durant le processus applicatif.

- Tu introduit une variable globale dans ton programme , ce qu'on aime éviter le plus possible.

Là justement, contrairement à ta suggestion dans ton premier commentaire, je n'ai pas créé de variable globale. À moins que tu considères le singleton comme étant de fait une variable globale ? Dans ce cas, autant se passer complètement du pattern singleton. Pourtant, j'ai vu dans ton Pry que tu utilises le singleton pour le routeur, ce que j'ai aussi fait de mon côté. Si c'est pertinent pour le routeur, pourquoi ne le serait-ce pas pour la collection d'erreurs éventuelles à afficher à l'utilisateur ?

- C'est pas vrai en PHP , mais dans un environnement multi threadé comme en C++ ou en JAVA le singleton risque d'induire des problème de concurrence si il n'est pas parfaitement géré.

Là, pas compris !

Il y'a quelques cas ou le singleton est intéressant , mais un gestionnaire d'erreur n'en fait probablement pas partie.

Donc, apparemment, selon ton propre framework, il y a le routeur. Quoi d'autre ? La classe d'accès à la BDD je suppose ? Et encore une fois, pourquoi pas la collection d'erreurs ?

Voilà un exemple de l'utilisation de mon singleton ErrorCollection, dans le contrôleur de connexion de l'utilisateur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
	/**
	 * Vérifie les données saisies par l'utilisateur dans le formulaire de connexion
	 */
	private function verifierFormulaire()
	{
		if(empty(trim($_POST['username'])))
		{
			ErrorCollection::getInstance()->ajouterErreur(new \ErrorException("Vous devez saisir votre nom d'utilisateur.")); // TODO i18n
		}
		else
		{
			$this->setLogin(trim($_POST['username']));
		}
 
		if(empty(trim($_POST['password'])))
		{
			ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Vous devez saisir votre mot de passe.')); // TODO i18n
		}
 
		if(count(ErrorCollection::getInstance()->getListeErreurs()) > 0)
		{
			// Erreur(s) trouvée(s) => on réaffiche la page de connexion avec erreur
			$this->afficherPageConnexion();
		}
	}

[grunk]

Je ne vois pas en quoi c'est problématique avec un singleton, justement ! Le singleton étant instancié par définition une seule fois, c'est juste un objet que j'utilise si nécessaire durant le processus applicatif.

C'est problématique , parce que si dans ta classe tu fais :

Code :

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

MonSingleton.getInstance().fairequelquechose();

Et bien ta classe devient fortement couplé à MonSingleton. Comprendre que si MonSingleton n'existe pas elle ne fonctionnera pas.
Ca peut aussi être un problème si tu veux tester unitairement ta classe.
Ici on est pas face à un problème fonctionnel , mais plutôt architectural. Pour ramener à une bdd ,sujet que tu maîtrise plus , c'est un peu comme une table non normalisé, ça marche, mais c'est pas l'idéal.

Là justement, contrairement à ta suggestion dans ton premier commentaire, je n'ai pas créé de variable globale. À moins que tu considères le singleton comme étant de fait une variable globale ?

Oui c'est le singleton qu'on considère comme variable globale, puisqu'il existe tout le temps et pour tout le monde

Dans ce cas, autant se passer complètement du pattern singleton. Pourtant, j'ai vu dans ton Pry que tu utilises le singleton pour le routeur, ce que j'ai aussi fait de mon côté. Si c'est pertinent pour le routeur, pourquoi ne le serait-ce pas pour la collection d'erreurs éventuelles à afficher à l'utilisateur ?

L'utilisation de singleton c'est un grand débat. Certains te dise qu'il ne faut jamais les utiliser. Je suis plus partisan d'une utilisation réfléchie.
Mais pour le cas du router , c'est pas forcément un bon candidat non plus pour le singleton. J'irais même jusqu'à dire que c'est une erreur de conception de mon Fw , mais comme ça marche et que ça me pose pas de pb je n'y touche pas

Un bon candidat pour un singleton c'est :
- Une classe qui ne doit avoir qu'une instance
- Une classe qui est tellement utiliser partout que l'injection de dépendance deviendrait ridicule
- Une classe qui gère une ressource accessible par plusieurs partie de ton applicatif.

L'exemple le plus courant c'est une classe de gestion des journaux.

Là, pas compris !

Dans le cas d'un programme avec plusieurs thread (ce qui n'existe pas en php) tu peux avoir des problème d'accès concurrent si ton singleton n'est pas ce qu'on appel thread safe. C'est pas forcément facile car il faut synchroniser les threads entre eux pour pas qu'il y'est de conflits. C'est pourquoi on conseille généralement d'éviter les singleton dans ces cas.
Le cas d'école, j'ai un singleton qui permet d'effacer un fichier ou d'y écrire. J'ai 2 thread qui exactement au même moment font ces deux actions. Si mon sigleton n'est pas thread safe je vais avoir un problème puisque je vais essayer d'écrire dans un fichier qu'un autre thread essai de supprimer.

Donc, apparemment, selon ton propre framework, il y a le routeur. Quoi d'autre ? La classe d'accès à la BDD je suppose ? Et encore une fois, pourquoi pas la collection d'erreurs ?

Attention mon FW n'est en rien une référence en terme d'architecture. je pense que c'est pas mal , mais c'est pas non plus parfait
Comme déjà dit les Journaux son l'exemple le plus couramment mis en avant pour un singleton.
La BDD éventuellement si celle ci ne gère pas les accès concurrent (sqlite dans certains cas par exemple). En revanche si c'est un serveur comme mysql, postgres, sqlserv , etc , ça n'a pas d'intérêt, ca peut même être intéressant d'avoir plusieurs connexion simultanées.

Pour ta collection d'erreur :

- Qu'est ce qui se passe si tu as 2 instances en même temps ? rien ? => pas de singleton
- Est ce qu'elle gère un accès à une ressource particulière ? non ? => pas de singleton
- Est ce qu'elle utiliser dans toute ton application ? non => pas de singleton


Je me répète mais le singleton c'est un peu débat idéologique sans fin. Il faut je pense limiter son utilisation au strict nécessaire sans tomber dans la phobie du singleton

[CinePhil]

Et bien ta classe devient fortement couplé à MonSingleton. Comprendre que si MonSingleton n'existe pas elle ne fonctionnera pas.

OK mais alors comment faire pour stocker au fil du processus les différentes erreurs applicatives éventuellement détectées afin de les afficher en fin de processus.

Concrètement, je développe une application pour enregistrer des personnes à former (étudiants et stagiaires). Toutes les infos sur ces personnes et leur formation ne sont pas forcément connues en même temps, ce qui implique un enregistrement des données en plusieurs passes avec les mêmes formulaires. Selon l'état de l'inscription, des informations sont nécessaires et pas d'autres qui le deviendront quand on voudra valider définitivement l'inscription. J'ai donc un processus d'ajout ou modification d'une inscription que je peux résumer ainsi :

1) Affichage du formulaire
2) L'utilisateur remplit complètement ou partiellement le formulaire ou complète les informations déjà connues.
3) Vérification de la cohérence de ce qui est saisi (date de diplôme supérieur cohérente avec la date du bac, date de naissance cohérente avec la date du bac, situation professionnelle de la personne cohérente avec la date de son dernier diplôme...).
4) Vérification de la présence minimum des informations requises selon l'état de l'inscription.
5) Enregistrement si tout va bien ou affichage des éventuels problèmes rencontrés par les tests précédents.

Les tests pourront dépendre de classes métier (par exemple, on souhaite ajouter une personne qui existe déjà en BDD détecté par une classe modèle après interrogation de la BDD) ou des contrôleurs (Ajout, Modification, Validation...).

C'est pour ça que je trouvais que l'idée d'avoir une seule instance d'une classe de collection d'erreurs serait pertinente.

Oui c'est le singleton qu'on considère comme variable globale, puisqu'il existe tout le temps et pour tout le monde

Euh... pour tout le monde ?
Sauf erreur de ma part, en PHP, les objets sont uniques à chaque flux et détruits en fin de processus, non ?
1) L'utilisateur A fait une requête.
2) L'application fait son boulot en instanciant ce qu'il faut et renvoie le résultat à l'utilisateur puis détruit tout ce qui a été utilisé, après avoir éventuellement stocké dans une session ce qui est prévu par le programme.

Si un utilisateur B vient faire une requête pendant le travail nécessaire à A, B ne va pas utiliser les objets de A mais avoir les siens propres, non ?
Donc il y aura une instance du singleton pour A et une instance du singleton pour B.

Mais pour le cas du router , c'est pas forcément un bon candidat non plus pour le singleton.

Pourtant, dans le processus PHP, le routeur est utilisé une fois et on peut avoir besoin de ses infos durant le déroulement du processus. Ça me semble pertinent d'utiliser un singleton.

Un bon candidat pour un singleton c'est :
- Une classe qui ne doit avoir qu'une instance

Oui, c'est même la définition d'un singleton, il me semble...

- Une classe qui est tellement utiliser partout que l'injection de dépendance deviendrait ridicule

Ben la ma collection d'erreur, j'en ai besoin partout dans mon code. Dans quasiment tous les contrôleurs et modèles.

- Une classe qui gère une ressource accessible par plusieurs partie de ton applicatif.

Qu'entends-tu par "ressource" ? La collection d'erreurs, c'est pas une ressource accessible à tous les contrôleurs ? Idem pour l'instance PDO pour que les modèles accèdent aux données (dans le cas où il n'y a qu'une seule BDD) ?

Pour ta collection d'erreur :

- Qu'est ce qui se passe si tu as 2 instances en même temps ? rien ? => pas de singleton

Justement, pour un utilisateur ayant fait une requête HTTP, il me faut une seule collection d'erreurs.

- Est ce qu'elle gère un accès à une ressource particulière ? non ? => pas de singleton

Encore une fois... ressource dans quel sens ?

- Est ce qu'elle utiliser dans toute ton application ? non => pas de singleton

Justement, la réponse est oui.

En programmation procédurale, j'aurais un fichier du genre gestion_erreur.php qui initialiserait un tableau des erreurs. Je ferais un include_once de ce fichier quelque part dans le processus et j'aurais accès de n'importe où à ses fonctions. Il me semblait que l'usage du singleton pouvait avantageusement permettre ça sans risquer d'ouvrir plusieurs tableaux d'erreurs et de finalement pas afficher toutes les erreurs rencontrées au cours du processus.


Sinon, comment faire mieux alors ?
Je n'ai pas fouillé à fond mais je n'ai pas trouvé de classe de gestion d'erreur dans Pry. Tu fais comment ?

[grunk]

OK mais alors comment faire pour stocker au fil du processus les différentes erreurs applicatives éventuellement détectées afin de les afficher en fin de processus.

De la même façon qu'avec ton singleton, sauf que c'est une instance de classe que tu passe aux classes qui en on besoin.

Euh... pour tout le monde ?

Je me suis pas mal exprimé , quand je parle de tout le monde je parle de toutes les classes de ton applications.

Donc il y aura une instance du singleton pour A et une instance du singleton pour B.

C'est tout à fait exact et c'est en partie pour cela que la notion de singleton en php est très discutable , puisque de toute manière tu risque de finir avec plusieurs instances de ton singleton

Pourtant, dans le processus PHP, le routeur est utilisé une fois et on peut avoir besoin de ses infos durant le déroulement du processus. Ça me semble pertinent d'utiliser un singleton.

Par définition le routeur on va le créer une fois et plus jamais l'utiliser , ou utiliser celui qu'on reçois en paramètres dans un controller par exemple. Donc le singleton n'a pas vraiment d'intérêt. Un développeur peut bien en instancier un 2ème si ca lui chante, il ne se passera rien, ca na cassera pas le fonctionnement de l'application.
De plus le router ne fait qu'instancier des controller (ressource) et si plusieurs controller son instancier en même temps on aura pas de problème.

Ben la ma collection d'erreur, j'en ai besoin partout dans mon code. Dans quasiment tous les contrôleurs et modèles.

Si effectivement tu en as besoin partout (et pas que dans les controller) le singleton pourrait se justifier pour la simplicité d'utilisation , même si les puristes te diront que d'un point de vue conceptuel ce n'est pas une raison valable.

Qu'entends-tu par "ressource" ? La collection d'erreurs, c'est pas une ressource accessible à tous les contrôleurs ? Idem pour l'instance PDO pour que les modèles accèdent aux données (dans le cas où il n'y a qu'une seule BDD) ?

Une ressource ca peut être tout et n'importe quoi. Un fichier, une connexion à une bdd, bref quelque chose qui à besoin d'être accédé.

Justement, pour un utilisateur ayant fait une requête HTTP, il me faut une seule collection d'erreurs.

Donc tu n'en n'instancie qu'une. Ce qu'il faut se demander c'est : si un nouveau développeur arrive sur le projet et instancie une seconde gestion d'erreur cela va t'il casser mon application ? Si oui alors le singleton est intéressant , il va éviter les problèmes. Si non , pas d'intérêt.

Sinon, comment faire mieux alors ?
Je n'ai pas fouillé à fond mais je n'ai pas trouvé de classe de gestion d'erreur dans Pry. Tu fais comment ?

Dans Pry je considère que c'est à l'utilisateur de gérer les erreurs. Chaque fonction retourne ce qu'il faut ou éventuellement lève une exception. A l'utilisateur d'en faire ce qu'il veux.

Pour moi la gestion d'erreur à vocation à être envoyé à l'utilisateur et doit donc être limité aux controllers.

Dans ton cas je verrais un truc du genre :

- Tu as une classe "controller_base" dont hérite tous tes controllers.
- controller_base contient une instance de ta classe de gestion d'erreur. Cette instance devra de préférence être injectée dans le controller plutôt que créer directement dedans.
- Chaque controller peut ainsi remplir la collection d'erreur en fonction des retour des models.
- Les models et autres code métier ne devrait pas avoir connaissance de la collection d'erreur et simplement avoir des retours de fonction adaptés voir des levé d'exception si nécessaire.