CLASSE DE GESTION AVANCÉE DES COOKIES

Commentaire de FhX le 16/04/2007 01:37:08

Du Get/Set en trop ^^

Utilise __get($var) et __set($var, $val) c'est tout aussi simple et rapide :)

$seen = $user->seen;
$seen++;
$$user->seen = $seen;
// ou :
$user->seen++;

Pareil pour le manager :
$user = $manager->nom_du_cookie;

Tu peux même garder en cache le contenu du cookie :

class manager {

  public function __get($cookiename) {
    if ( !isset(self::$_cookie[$cookiename]) )
         self::$_cookie[$cookiename] = new Cookie($cookiename);
   return self::$_cookie[$cookiename];
  }

}

Ce qui permet par la suite :
$manager->nom_du_cookie->seen++;

unset($manager->nom_du_cookie); // détruira l'objet.
Tout ca tranquillement :)

Bref, quelques petits trucs à revoir (je précise que j'ai pas regardé le fichier source. J'ai juste regardé comment tu as présenté ton exemple.
En bref, je n'ai regardé que l'interface pour utiliser tes objets, pas le code en profondeur :))

Commentaire de oox le 22/04/2007 12:19:24

Je pense que ton singleton est bien trop lourd pour une telle classe. Tu as ajouter un certain nombre de méthodes fortuites selon moi ... Pour ton singleton :

private static $_instance = null;

public function getInstance()
{
    if (self::$_instance === null) self::$_instance = new self();
    return self::$_instance;
}

private function __construct() { ... }

Commentaire de FhX le 25/04/2007 15:33:03

"autant parce que c'est moins rapide à l'exécution que parce que cela ne marche pas dans le cas où l'on utilise des noms de membres existants (Name, Expiration, Variables)."
Totalement faux.
Contre-exemple :

class x {
private $y;

public function get($var) {
  return $this->$var;
}
public function set($var, $val) {
  $this->$var = $val;
}
}
// Je passe volontairement sur les tests de détection de propriétées existantes où non.

$x = new x;
echo $x->y;
$x->y = 10;
echo $x->y;

Ca marche aussi bien.

Si tu as une classe qui possède 30getters, 30 setters... c'est qu'il y a un problème de conception de ta classe.
Moi je m'amuse pas à ca, la programmation n'est pas faite pour se compliquer la vie, mais bien de la rendre plus facile.

Moins rapide à l'éxécution ? Parce que tu trouves que :
public function getY() {
  return $this->y;
}
C'est rapide ?
Ca ne sert strictement à rien ce genre de truc.

public function __get($var) {
if ( property_exists($this, $var) )
  return $this->$var;
}

Mais généralement, tu utilises __get() quand tu as un tableau en propriété :

private $array = array('x' => 'machin', 'y'=>'truc');
public function __get($var) {
if ( property_exists($this, $var) )
      return $this->$var;
elseif ( array_key_exists($var, $array) )
      return $this->array[$var];
else
      throw new Exception(...);
}

Voila à quoi sert un Getter généralisé. A ne plus se faire chier avec 30 getters/setter qui remplissent des lignes inutilements.

Commentaire de FhX le 25/04/2007 19:16:52

"ne serait-ce que pour la gestion des erreurs."
En effet, et pour cela pas besoin de 30 get/set.
A partir du moment ou tu as 2 méthodes :
getTruc() return $this->truc;
setTruc($val) $this->truc = $val;

Y'a un problème.
Autant mettre la propriété en public.

"alors que la vérification de l'existence des méthodes getMachin() et setMachin($valeur) a lieu lors de la phase de compilation."
Totalement faux aussi. Je peux faire une méthode qui va faire un get() sur une propriété inexistante, et l'erreur ne se produira que lors de l'appel de la méthode erronée.

Y'a un bench pour prouver que get/set est plus lent ?

Commentaire de FhX le 25/04/2007 21:16:32

Youpi, jme suis trouvé quelqu'un à qui parler !

"Tu connais les principes de la POO ?"
Non, je ne connais absolument rien de la POO, tu as totalement raison.

"Ca te dit quelque chose le principe d'encapsulation ?"
Le principe d'encapsulation n'a jamais obligé le developpeur a n'utiliser exclusivement le private/protected et a bannir le public.
Il est certe utilisé pour faire une "boite noire" pour chaque instance de classe, et cela est utile lorsque l'on veut filtrer les données entrantes.

Cependant, l'orientée objet n'oblige pas l'utilisation de ce principe, et c'est bien là où tu fais erreur. Pour toi, objet = principe d'encapsulation. C'est totalement faux. Je n'ai jamais entendu rien de tel jusqu'à présent.
L'utilisation du statissisme par exemple ne fait pas partie du principe d'encapsulation.
Avant de me balancer le principe d'encapsulation en pleine tronche simplement pour faire beau, fais attention à ne pas faire l'analgame : "je fais un objet, j'utilise forcément le principe d'encapsulation".

"Sur le second point, tu mélange absolument tout, je parle d'une méthode getMachin(), pas d'une méthode get($machin), car évidemment, dans cette dernière version, c'est équivalent à __get($machin)."
J'avoue que même en me relisant, je ne comprends toujours pas ce que tu viens de me dire. Ah si ca y est :
"Je peux faire une méthode qui va faire un get() sur une propriété inexistante, et l'erreur ne se produira que lors de l'appel de la méthode erronée."
Il fallait y lire :
"Je peux faire une méthode qui va faire un getMachin() sur une propriété inexistante, et l'erreur ne se produira que lors de l'appel de la méthode erronée."

"Alors, avant d'affirmer que quelque chose est "totalement faux", essaie de comprendre ce que te dis ton interlocuteur et renseigne toi sur le fonctionnement d'un interpréteur/compilateur."
Ouh, alors la c'est dur comme critique. Je ne pensais pas que quelqu'un irait jusque la. Je pensais qu'avoir fait des sources largement orientées objet ici me prémunirais contre ce genre d'attaque infondée.


J'ai autre chose à branler que de venir cracher sur toi ou sur quiconque. Car, si c'est bel et bien à cela que tu te destines en voulant te confronter à moi, sache que je suis pret à changer le ton de mes réponses.
Pour le moment, je me veux le plus courtois possible. Ce n'est pas parce que j'ai dis que ton raisonement était faux que j'ai dis que tu étais un pauvre naze et qu'il fallait que tu fermes ta gueule parce que tu avais tord.

Je suis ouvert à tout débat, en particulier sur la POO, tant que cela reste dans le cadre du respect. J'ignorerai donc tes attaques personnelles cette fois ci, mais si cela revient à recommencer une nouvelle fois, je n'hésiterai pas à passer moi aussi à l'offensive.

Mais pour le moment, le niveau de mes sources comparé aux tiennes me confortent dans l'idée que pour le moment, je ne crains absolument rien de ta part :)


Sur ce, je mentiens ce que je dis. En effet, tu n'as pas réussi à me convaincre du mal-fondé de mes pensées... en tout cas pas avec 4 phrases chocs et un lien sur wikipedia :s
Si tu comptes me faire valoir ton point de vue, il va falloir trouver mieux.

Je suis ouvert à tout.

Commentaire de FhX le 26/04/2007 20:14:24

Je suis d'accord avec toi sur le fait d'évolution garanti avec l'encapsulation. Il est vrai qu'il est l'unique moyen d'être sûr à 100% que lors d'une modification de la classe, les choses marcheront toujours de la même facon.
Mais généralement, quand on utilise une propriété publique, c'est qu'on s'en fou un peu quand même.
Par exemple, une classe SQL. Tu peux récupérer le numéro de version du serveur MySQL, mais pas besoin d'un getter pour ca, il suffit de mettre la propriété en publique. Qu'importe de toute facon, elle ne fait rien de bien spécifique à la classe de toute facon.

Voila pourquoi je disais qu'il ne faut pas tout encapsuler :) Mais d'une manière générale oui il le faut.

Le statissisme, oui c'est l'espace de nom. C'est un concept objet également (bien que...).


L'autre problème que de faire du get/set, c'est qu'il faut créer l'interface qui va avec. Depuis PHP5, on associe les get/set avec une interface qu'on va inclure à la classe, et de ce fait on ne se reporte qu'à l'interface pour l'accès au méthode.

L'encapsulation est une bonne chose, mais doit être utilisé correctement :)