[PHP5] FORMCHECKER : VALIDATION DE SAISIES UTILISATEUR
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 2015
-
5 janv. 2007 à 15:46
Phelim
Messages postés1Date d'inscriptionmercredi 26 avril 2006StatutMembreDernière intervention 1 mars 2008
-
1 mars 2008 à 21:30
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
Phelim
Messages postés1Date d'inscriptionmercredi 26 avril 2006StatutMembreDernière intervention 1 mars 2008 1 mars 2008 à 21:30
C'est une source très utile.
C'est extrêmement complet et efficace.
Par contre, je ne vois pas forcément l'intérêt des fonctions d'utilisateurs.
Il est facile et plus propre de réaliser d'autres classes de validation ou d'étendre les class existantes.
Etant donné que tout est bon ( convention de codages, documentation, modularité ), je donne la note maximal a cette source
DiGhan
Messages postés239Date d'inscriptionsamedi 21 février 2004StatutMembreDernière intervention 3 juin 20101 11 juil. 2007 à 23:45
Cette source est réellement bien menée ! La gestion des erreurs, le process d'appel à validate(), autant de choses qui en font un excellent outil.
En bref, du trés bon travail !
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 27 janv. 2007 à 15:24
C'est un compliment...? lol ?
Pour revenir à l'anglais, le truc c'est que je commente mes codes en anglais. Je me vois mal faire 2 fichiers, 1 avec le code commenté en anglais et 1 avec le code commenté en français, spécialement pour CS.
L'anglais que j'utilise est super basique, bourré de fautes parce que je commente généralement très vite sans faire particulièrement attention, et donc à priori compréhensible même si on est mauvais en anglais ;-)
Epoc22
Messages postés198Date d'inscriptionlundi 28 février 2005StatutMembreDernière intervention14 novembre 20081 27 janv. 2007 à 11:22
malalam tu fait de ces trucs de fou... hallucinant
Epoc22
Messages postés198Date d'inscriptionlundi 28 février 2005StatutMembreDernière intervention14 novembre 20081 25 janv. 2007 à 13:13
Je n'ai pas dit que j'était un merde an anglais (au contraire) mais bon... ici c'est un site d'échanges francophone.
Voila @
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 24 janv. 2007 à 19:18
La semaine prochaine...heu... ;-)
Epoc22 => je ne partage pas forcément QUE pour des français...je ne travaille pas non plus forcément QU'AVEC des français...
Donc, je documente en anglais.
Et ça, même la semaine prochaîne, je ne le changerai pas ;-)
Ceci dit, tu noteras que dans le zip, il y a une documentation sur l'utilisation en français, hein...;-)
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 24 janv. 2007 à 18:12
Tu verras par toi même que beaucoup de code en programmation sont en anglais.
C'est comme ca, faut t'y faire :)
Epoc22
Messages postés198Date d'inscriptionlundi 28 février 2005StatutMembreDernière intervention14 novembre 20081 24 janv. 2007 à 17:03
Salut,
c'est un peu chiant la doc est en anglais...
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 12 janv. 2007 à 19:56
si si, 'scuse, j'ai pas du tout eu le temps de me repencher dessus cette semaine.
Verrai ça la semaine prochaine (si tout va bien lol).
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 12 janv. 2007 à 19:19
Jvois que ca emballe pas :p
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 9 janv. 2007 à 20:37
Je me demande pourquoi c'est encore la ca :
FormChecker::validate();
public function validate ($mString, $sName, $cPattern, $aOptions null, $bMandatory true);
Alors..., je décortique :
$mString, c'est la chaine à traiter.
$sName, c'est le nom que tu vas donner à ta chaine (pourquoi ? va savoir :s)
$cPattern, c'est le type de classe que tu vas instancier (hu ? )
$aOptions, ce sont les options de ta classe (la aussi... hu ?)
$bMandatory, encore une autre option un peu spécial.
Orienté objet, y'a comme une erreur la dedand. Tu fais passer en paramètre le type de classe ainsi que les options séparément ?
Pourquoi tu n'as pas retenu mon idée d'origine, c'est à dire de faire :
public function validate ($oObject, $bMandatory = true);
Avec :
$oObject, la classe d'objet instanciée.
$bMandatory, ton option "spéciale".
?
Ton constructeur d'objet devra ressembler à ca :
public function __construct($mString, $aOptions=NULL);
Et pour appeler ta méthode formchecker::validate(), suffit de faire :
return ( $oFormChecker->validate( new validateInt(95000) ) ) ? TRUE : FALSE;
C'est pas plus facile à lire ? A coder aussi je crois non ?
C'est peut être plus lourd niveau temps d'exécution alors ?
Parce qu'après, le code de FormChecker::validate il ressemble à ca :
public function validate($oObject, $bMandatory=TRUE) {
try {
$bRes = $oObject -> validate ($bMandatory);
} catch (Exception $e) {
self::$aMsg[$sName] = $e -> getMessage ();
$bRes $this -> bValid false;
}
return $bRes;
}
En plus, je suis sur que tu peux te passer de cette classe formchecker... Mais c'est une autre histoire.
Tu peux essayer ma méthode pour voir ? Pas trop le temps en ce moment pour te pondre tout le code mais jvais essayer de le faire à ma sauce et faudra juste que tu me le bench par contre :p
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 8 janv. 2007 à 09:27
Nan, po un vrai... ;-)
C't'en ligne :-)
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 7 janv. 2007 à 15:54
Mince, tu dors pas à ton taff ??
T'es pas un vrai Geek du PHP Mala... rahhhh :p
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 6 janv. 2007 à 11:02
je peux pas, il est à mon taf, pas chez moi, et le week-end, suis chez moi ;-)
Donc ce sera lundi :-)
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 5 janv. 2007 à 21:34
Yes ! :p
Fait envoyer le nouveau code maintenant... doit y avoir encore des trucs à parfaire :D
M'est avis que tu seras toujours un peu plus lent que ton bouzin d'avant ... quoi que :/
Jvais m'y pencher demain ^^
Envoi le nouveau code quoi !! Aller ! :p
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 5 janv. 2007 à 19:35
je sais, lol, je suis passé par un stockage de la variable $loc, en statique.
Je regarde ma propriété (validateGen::$sloc) est différente du paramètre passé, si oui, j'instancie sLocClass, sinon non. Comme ça on peut changer de languer au sein du même script (ce qui est, convenons-en, assez peu probable, mais bon...).
Ben en fait là, je suis tjrs plus lent qu'avec la classe originale.
Mais c'est plus joli ;-) (je mettrai à jour la semaine prochaine).
J'ai mis, donc : bcp de méthodes en statique, la propriété sLocClass, j'ai passé en privée quelques méthodes aussi, et j'ai foutu les exceptions à la place des formChecker::$aMsg...bla bla, que j'ai juste mis dans le catch.
Le code est aussi un peu plus court.
Reste à retrouver la vitesse d'antan lol...mais on verra. Suis passé de 0.00086... à 0.00095 en moyenne, au final.
Donc je perds 0.0001 seconde sur ce petit script (la version française uniquement, c'est ce que j'ai benché). Pas énorme de toute manière.
Donc oui, l'optimisation à la FhX a fonctionné à merveille ;-)
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 5 janv. 2007 à 18:53
Aller, dis leur que l'optimisation à la FhX fonctionne à merveille :p
Pour if ( !isset(self::LocClass) ) self::LocClass = formCheckerMessages::factory ($loc); j'avais oublié de te dire que étant donné qu'on appèlle la même classe à chaque fois, ca fait une instance à chaque appel :p Bah vi, c'est un Singleton ca... :p
Et voila :) Chui content d'avoir eu raison sur le statique... j'ai eu peur quand tu m'as dit que ca prenait plus de temps :o
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 5 janv. 2007 à 18:38
Oui c'est à cause des données pouvant être vides ET Valides, ou vides ET invalides.
Du coup j'ai 3 cas dans la méthode validate de la classe mère. Mais ça ne me plait pas non plus...je n'ai juste pas trouvé d'autre moyen.
En fait l'intérêt de scinder autant est que si jamais je n'ai que une donnée de type texte à vérifier (ou 2), je ne récupère pas des méthodes inutiles dédiées aux emails, url, type numériques etc...
De plus, cela facilite l'évolution des classes, et la création de nouvelles classes. Le processus est implémenté, et ajouter un masque, par exemple, demande juste l'implémentation d'une classe fille. Et tout le reste est déjà géré.
Lors du dév de ce package, ça s'est révélé très efficace par rapport à ma méthode d'avant qui regroupait tout en une classe (ou presque).
Ca, je garde mes petites classes filles lol ;-)
Par contre j'optimise (bon là ce n'est pas flagrant, j'ai perdu un peu de rapidité...mais y a des exceptions lol et c'est encore plus facilement gérable...mais j'espère arriver à plus optimisé).
Et au niveau de l'utilisation en elle-même, une fois qu'on a compris comment se faisait les appels de masque avec les options (ça ok, c'est pas évident..mais en même temps c'est plutôt puissant), c'est très facile à implémenter dans un code.
mais je suis d'accord, c'est loin d'être parfait. En fait, je vais approfondir le côté Reflection, parce que je pense qu'on peut gagner du temps avec (j'en suis pas certain non plus hein...).
kankrelune
Messages postés1293Date d'inscriptionmardi 9 novembre 2004StatutMembreDernière intervention21 mai 2015 5 janv. 2007 à 17:46
Ah merde... j'avais pas vu le -1 en retour... désolé... .. .
@ tchaOo°
kankrelune
Messages postés1293Date d'inscriptionmardi 9 novembre 2004StatutMembreDernière intervention21 mai 2015 5 janv. 2007 à 17:41
Pareil que FhX... je trouve ça assez lourd... je ne vois pas l'interet de faire autant de class fille pour une méthode à chaque fois... je pense que tout pourrais être regroupé en une ou deux class... mais c'est un choix tu as peut être des raisons pour... .. .
$bRes ne peut être que booléen il me semble... alors pourquoi un double test... .. ?
@ tchaOo°
ps : bonne année à vous deux... .. .
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 5 janv. 2007 à 17:32
Donc après tests, pour l'instant, c'est plus lent de passer les méthodes en statique. Alors que je suis plutôt d'accord avec toi dans l'absolu lol.
Par contre, je vais voir pour tes exceptions...en effet, et gérer ça en dehors avec un bloc try catch.
Pour le reste on verra! Je vais voir ce que je peux faire par rapport à la réflexion...le problème à la base était de récupérer mes constantes. Evidemment, si je m'en passe...je peux aussi me passer de la réflexion. mais j'aimais bien l'idée des constantes de classe pour appeler les masques lol.
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 5 janv. 2007 à 16:39
Alors voila.
Après avoir pris ma douche et tout et tout... voila comment j'aurais fait :p
public function __construct($mString, $sName, $aOptions=NULL, $bMandatory=TRUE) {
$this->mString = $mString...; // etc...
}
public function validate() {
if ( !parent::validate() ) {
return false;
} else {
// if pregmatch...()
}
}
}
// Puis dans formChecker::validate();
class formchecker {
public function validate ($oObject) {
if (false ($bRes $oObject -> validate () ) ) {
$this -> bValid = false;
}
return $bRes;
}
}
// et dans ton exemple :
if (false === $oChecker -> validate (new validateUrl($sUrl, 'url') )) {
// etc...
} else {
// etc...
}
Voila un peu comment je voyais ca :)
Dans la théorie, c'est censé fonctionner... ca nécessite de remanier un peu le code dans la classe abstraite mais voila à peu près les grandes lignes :)
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 5 janv. 2007 à 15:46
C'est ca oui ...
@return unknown sur une variable boolean ? ;)
J'aime bien pour ma part (apparament, t'a tué tout le monde, personne vient poster :p)...
Juste que c'est un poil trop lourd je trouve.
Surtout au niveau du :
# $oReflect = new ReflectionClass($cPattern);
# $o = $oReflect -> newInstance ();
Parce que tu vas faire une instance de validateUrl par exemple et qui va récupérer TOUTES les méthodes de ta classe abstraite, et puis une autre instance de validateInt par exemple et qui va elle aussi récupérer TOUTES les méthodes de ta classe abstraite INDEPENDEMENT de l'instance "validateUrl".
J'imagine la duplication de code en mémoire lorsque tu instancies toutes les classes filles :)
Je pense que certaines méthodes dans ta classe abstraite doivent passer en statique car elles sont communes à toutes les instances au final... y'a pas une grande spécificité entre les instances.
Si je peux te donner un conseil, c'est celui la. Passer les méthodes en statiques (ca va t'obliger à revoir un peu le code par contre ^^) et puis je pense que c'est tout.
Si, y'a peut être autre chose, mais ca on verra plus tard, jviens de me lever et j'ai faim ^^
Ah vi, fait un bench de ton exemple avant de mettre quoi que ce soit en statique (donc tes classes en l'état), et essaye après. Normalement, tu récupères un peu de ces precieuses millisecondes :p (et surtout un peu de mémoire aussi ^^).
Cependant, le concept est pas mal en lui même, tout est fonctionnel... mais peut être un peu dur à comprendre du premier coup pour quelqu'un qui pige quedalle (surtout au niveau des arguments de ->validate() :p)
Si j'ai le temps, je t'expose mon autre théorie dans la journée... tu vas voir ^^
1 mars 2008 à 21:30
C'est extrêmement complet et efficace.
Par contre, je ne vois pas forcément l'intérêt des fonctions d'utilisateurs.
Il est facile et plus propre de réaliser d'autres classes de validation ou d'étendre les class existantes.
Etant donné que tout est bon ( convention de codages, documentation, modularité ), je donne la note maximal a cette source
11 juil. 2007 à 23:45
En bref, du trés bon travail !
27 janv. 2007 à 15:24
Pour revenir à l'anglais, le truc c'est que je commente mes codes en anglais. Je me vois mal faire 2 fichiers, 1 avec le code commenté en anglais et 1 avec le code commenté en français, spécialement pour CS.
L'anglais que j'utilise est super basique, bourré de fautes parce que je commente généralement très vite sans faire particulièrement attention, et donc à priori compréhensible même si on est mauvais en anglais ;-)
27 janv. 2007 à 11:22
25 janv. 2007 à 13:13
Voila @
24 janv. 2007 à 19:18
Epoc22 => je ne partage pas forcément QUE pour des français...je ne travaille pas non plus forcément QU'AVEC des français...
Donc, je documente en anglais.
Et ça, même la semaine prochaîne, je ne le changerai pas ;-)
Ceci dit, tu noteras que dans le zip, il y a une documentation sur l'utilisation en français, hein...;-)
24 janv. 2007 à 18:12
C'est comme ca, faut t'y faire :)
24 janv. 2007 à 17:03
c'est un peu chiant la doc est en anglais...
12 janv. 2007 à 19:56
Verrai ça la semaine prochaine (si tout va bien lol).
12 janv. 2007 à 19:19
9 janv. 2007 à 20:37
FormChecker::validate();
public function validate ($mString, $sName, $cPattern, $aOptions null, $bMandatory true);
Alors..., je décortique :
$mString, c'est la chaine à traiter.
$sName, c'est le nom que tu vas donner à ta chaine (pourquoi ? va savoir :s)
$cPattern, c'est le type de classe que tu vas instancier (hu ? )
$aOptions, ce sont les options de ta classe (la aussi... hu ?)
$bMandatory, encore une autre option un peu spécial.
Orienté objet, y'a comme une erreur la dedand. Tu fais passer en paramètre le type de classe ainsi que les options séparément ?
Pourquoi tu n'as pas retenu mon idée d'origine, c'est à dire de faire :
public function validate ($oObject, $bMandatory = true);
Avec :
$oObject, la classe d'objet instanciée.
$bMandatory, ton option "spéciale".
?
Ton constructeur d'objet devra ressembler à ca :
public function __construct($mString, $aOptions=NULL);
Et pour appeler ta méthode formchecker::validate(), suffit de faire :
return ( $oFormChecker->validate( new validateInt(95000) ) ) ? TRUE : FALSE;
C'est pas plus facile à lire ? A coder aussi je crois non ?
C'est peut être plus lourd niveau temps d'exécution alors ?
Parce qu'après, le code de FormChecker::validate il ressemble à ca :
public function validate($oObject, $bMandatory=TRUE) {
try {
$bRes = $oObject -> validate ($bMandatory);
} catch (Exception $e) {
self::$aMsg[$sName] = $e -> getMessage ();
$bRes $this -> bValid false;
}
return $bRes;
}
En plus, je suis sur que tu peux te passer de cette classe formchecker... Mais c'est une autre histoire.
Tu peux essayer ma méthode pour voir ? Pas trop le temps en ce moment pour te pondre tout le code mais jvais essayer de le faire à ma sauce et faudra juste que tu me le bench par contre :p
8 janv. 2007 à 09:27
C't'en ligne :-)
7 janv. 2007 à 15:54
T'es pas un vrai Geek du PHP Mala... rahhhh :p
6 janv. 2007 à 11:02
Donc ce sera lundi :-)
5 janv. 2007 à 21:34
Fait envoyer le nouveau code maintenant... doit y avoir encore des trucs à parfaire :D
M'est avis que tu seras toujours un peu plus lent que ton bouzin d'avant ... quoi que :/
Jvais m'y pencher demain ^^
Envoi le nouveau code quoi !! Aller ! :p
5 janv. 2007 à 19:35
Je regarde ma propriété (validateGen::$sloc) est différente du paramètre passé, si oui, j'instancie sLocClass, sinon non. Comme ça on peut changer de languer au sein du même script (ce qui est, convenons-en, assez peu probable, mais bon...).
Ben en fait là, je suis tjrs plus lent qu'avec la classe originale.
Mais c'est plus joli ;-) (je mettrai à jour la semaine prochaine).
J'ai mis, donc : bcp de méthodes en statique, la propriété sLocClass, j'ai passé en privée quelques méthodes aussi, et j'ai foutu les exceptions à la place des formChecker::$aMsg...bla bla, que j'ai juste mis dans le catch.
Le code est aussi un peu plus court.
Reste à retrouver la vitesse d'antan lol...mais on verra. Suis passé de 0.00086... à 0.00095 en moyenne, au final.
Donc je perds 0.0001 seconde sur ce petit script (la version française uniquement, c'est ce que j'ai benché). Pas énorme de toute manière.
Donc oui, l'optimisation à la FhX a fonctionné à merveille ;-)
5 janv. 2007 à 18:53
Pour if ( !isset(self::LocClass) ) self::LocClass = formCheckerMessages::factory ($loc); j'avais oublié de te dire que étant donné qu'on appèlle la même classe à chaque fois, ca fait une instance à chaque appel :p Bah vi, c'est un Singleton ca... :p
Et voila :) Chui content d'avoir eu raison sur le statique... j'ai eu peur quand tu m'as dit que ca prenait plus de temps :o
5 janv. 2007 à 18:38
Du coup j'ai 3 cas dans la méthode validate de la classe mère. Mais ça ne me plait pas non plus...je n'ai juste pas trouvé d'autre moyen.
En fait l'intérêt de scinder autant est que si jamais je n'ai que une donnée de type texte à vérifier (ou 2), je ne récupère pas des méthodes inutiles dédiées aux emails, url, type numériques etc...
De plus, cela facilite l'évolution des classes, et la création de nouvelles classes. Le processus est implémenté, et ajouter un masque, par exemple, demande juste l'implémentation d'une classe fille. Et tout le reste est déjà géré.
Lors du dév de ce package, ça s'est révélé très efficace par rapport à ma méthode d'avant qui regroupait tout en une classe (ou presque).
Ca, je garde mes petites classes filles lol ;-)
Par contre j'optimise (bon là ce n'est pas flagrant, j'ai perdu un peu de rapidité...mais y a des exceptions lol et c'est encore plus facilement gérable...mais j'espère arriver à plus optimisé).
Et au niveau de l'utilisation en elle-même, une fois qu'on a compris comment se faisait les appels de masque avec les options (ça ok, c'est pas évident..mais en même temps c'est plutôt puissant), c'est très facile à implémenter dans un code.
mais je suis d'accord, c'est loin d'être parfait. En fait, je vais approfondir le côté Reflection, parce que je pense qu'on peut gagner du temps avec (j'en suis pas certain non plus hein...).
5 janv. 2007 à 17:46
@ tchaOo°
5 janv. 2007 à 17:41
Sinon... dans les classes filles de validateGen
if (false ($bRes parent::validate (... .. .))) {
return false;
} elseif (true === $bRes)
$bRes ne peut être que booléen il me semble... alors pourquoi un double test... .. ?
@ tchaOo°
ps : bonne année à vous deux... .. .
5 janv. 2007 à 17:32
Par contre, je vais voir pour tes exceptions...en effet, et gérer ça en dehors avec un bloc try catch.
Pour le reste on verra! Je vais voir ce que je peux faire par rapport à la réflexion...le problème à la base était de récupérer mes constantes. Evidemment, si je m'en passe...je peux aussi me passer de la réflexion. mais j'aimais bien l'idée des constantes de classe pour appeler les masques lol.
5 janv. 2007 à 16:39
Après avoir pris ma douche et tout et tout... voila comment j'aurais fait :p
*****
*****
Je vais prendre ta classe validateUrl :
class validateUrl extends validateGen {
private $mString;
private $sName;
private $aOptions;
private $bMandatory;
public function __construct($mString, $sName, $aOptions=NULL, $bMandatory=TRUE) {
$this->mString = $mString...; // etc...
}
public function validate() {
if ( !parent::validate() ) {
return false;
} else {
// if pregmatch...()
}
}
}
// Puis dans formChecker::validate();
class formchecker {
public function validate ($oObject) {
if (false ($bRes $oObject -> validate () ) ) {
$this -> bValid = false;
}
return $bRes;
}
}
// et dans ton exemple :
if (false === $oChecker -> validate (new validateUrl($sUrl, 'url') )) {
// etc...
} else {
// etc...
}
Voila un peu comment je voyais ca :)
Dans la théorie, c'est censé fonctionner... ca nécessite de remanier un peu le code dans la classe abstraite mais voila à peu près les grandes lignes :)
5 janv. 2007 à 15:46
# * @return unknown
# */
# public function isValid () {
# return $this -> bValid;
# }"
C'est ca oui ...
@return unknown sur une variable boolean ? ;)
J'aime bien pour ma part (apparament, t'a tué tout le monde, personne vient poster :p)...
Juste que c'est un poil trop lourd je trouve.
Surtout au niveau du :
# $oReflect = new ReflectionClass($cPattern);
# $o = $oReflect -> newInstance ();
Parce que tu vas faire une instance de validateUrl par exemple et qui va récupérer TOUTES les méthodes de ta classe abstraite, et puis une autre instance de validateInt par exemple et qui va elle aussi récupérer TOUTES les méthodes de ta classe abstraite INDEPENDEMENT de l'instance "validateUrl".
J'imagine la duplication de code en mémoire lorsque tu instancies toutes les classes filles :)
Je pense que certaines méthodes dans ta classe abstraite doivent passer en statique car elles sont communes à toutes les instances au final... y'a pas une grande spécificité entre les instances.
Si je peux te donner un conseil, c'est celui la. Passer les méthodes en statiques (ca va t'obliger à revoir un peu le code par contre ^^) et puis je pense que c'est tout.
Si, y'a peut être autre chose, mais ca on verra plus tard, jviens de me lever et j'ai faim ^^
Ah vi, fait un bench de ton exemple avant de mettre quoi que ce soit en statique (donc tes classes en l'état), et essaye après. Normalement, tu récupères un peu de ces precieuses millisecondes :p (et surtout un peu de mémoire aussi ^^).
Cependant, le concept est pas mal en lui même, tout est fonctionnel... mais peut être un peu dur à comprendre du premier coup pour quelqu'un qui pige quedalle (surtout au niveau des arguments de ->validate() :p)
Si j'ai le temps, je t'expose mon autre théorie dans la journée... tu vas voir ^^