CLASSE DE GESTION AVANCÉE DES COOKIES

Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
- - Dernière réponse : marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
- 20 juil. 2007 à 01:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/42290-classe-de-gestion-avancee-des-cookies

marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
-
C'est pas grave
marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
-
Bonjour,

Votre script ne fonctionne pas sur deux serveurs différent et aussi sur EasyPHP 2.0.0.0
Ou c'est une erreur ligne 8 dans index.php
Parse error: parse error, unexpected '{' in /homepages/30/d160718081/htdocs/Le-Facturier/teste/phpcs_CLASSE-GESTION-AVANC-201-COOKIES_42290/index.php on line 8

Ou sur un autre serveur ligne est EasyPhp Ligne106 dans cookie.class.php

Fatal error: Cannot use string offset as an array in D:\Program Files\EasyPHP 2.0b1\www\phpcs_CLASSE-GESTION-AVANC-201-COOKIES_42290\cookies\cookie.class.php on line 106


Comment corriger ce problème car je cherche un m?oyent d'enregistrer les valeurs des champs d'un formulaire.


Merci
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
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 :)
Gorrk
Messages postés
96
Date d'inscription
mercredi 16 avril 2003
Statut
Membre
Dernière intervention
26 avril 2007
-
Je suis désolé de mettre laissé emporter dans mon dernier message, je n'avais pas vu que tu était "le plus courtois possible" et "ouvert à tout débat", j'ai certainement mal interprété ton "totalement faux" car il m'a semblé que tu étais fermé et condescendant, et je m'en excuse donc.

Avant de clore cette discussion qui me semble stérile (désolé LocalStone de légèrement encombrer ton post), je souhaiterais revenir sur le principe d'encapsulation qui est, selon moi, un des principes les plus importants de la POO (avec l'héritage, le polymorphisme, ...) car c'est elle qui garantie l'évolutivité de ton code : si tu t'aperçois finalement que tu dois vérifier quelque chose lors de la mise un jour d'un membre, le fait de l'avoir déclaré public et de le modifier directement va compliquer la mise à jour de ton code et va (probablement) t'obliger à changer également les sources reposant sur ta classe pour, par exemple, remplacer la modif. directe du membre par une méthode chargée de la vérification. Alors que si tu utilisais depuis le début des méthodes d'accès, tu n'aurais qu'a la modifier quelque peu.

Sinon, qu'appelle tu le statissisme ? C'est le fait de regrouper des fonctions dans un espace de nom ?
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
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.
Gorrk
Messages postés
96
Date d'inscription
mercredi 16 avril 2003
Statut
Membre
Dernière intervention
26 avril 2007
-
Tu connais les principes de la POO ?
Ca te dit quelque chose le principe d'encapsulation ?
On ne doit jamais, je dit bien jamais mettre une propriété en public.
Jette un oeil sur cette article de Wikipédia : http://fr.wikipedia.org/wiki/Encapsulation_%28programmation%29.

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

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.
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
"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 ?
Gorrk
Messages postés
96
Date d'inscription
mercredi 16 avril 2003
Statut
Membre
Dernière intervention
26 avril 2007
-
Après reflexion, je suis d'accord avec toi, dans le cas où l'on travaille avec des attributs dont on ne connait pas le nom au moment du code, on peut utiliser __get() et __set(), mais dans le cas où l'on sais sur quel membre travailler, il est bien mieux de faire des getMachin() et des setMachin($valeur), ne serait-ce que pour la gestion des erreurs. D'autant plus qu'il est plus lent (je persiste) de faire ces vérifications dans __get() ou __set() car elles n'ont lieu qu'à l'execution alors que la vérification de l'existence des méthodes getMachin() et setMachin($valeur) a lieu lors de la phase de compilation.

Quand je dis que "cela ne marche pas dans le cas où l'on utilise des noms de membres existants", c'est vrai, dans ton dernier exemple, "echo $object->array;" ne fonctionnera pas car le membre existe et sa visibilité es private.

Manuel PHP :
Les appels de méthodes et l'accès aux membres peuvent être surchargés via les méthodes __call(), __get() et __set(). Ces méthodes ne seront déclenchées que si votre objet, hérité ou non, ne contient pas le membre ou la méthode auquel vous tentez d'accéder.
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
"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.
Gorrk
Messages postés
96
Date d'inscription
mercredi 16 avril 2003
Statut
Membre
Dernière intervention
26 avril 2007
-
Bon, personnellement, je pense pas que ce soit intéressant de mettre en public la fonction clone() et de renvoyer une exception, n'aurait-ce pas été plus simple de le mettre en private ?

Sinon, oui, la fonction getInstance est incorrecte : elle retourne une nouvelle instance à chaque appel, prend exemple sur celle de oox.

Dans un autre domaine, je ne pense pas qu'il soit mieux d'utiliser __get et __set que de créer des "getter" et des "setter" classiques, 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).
cs_oox
Messages postés
6
Date d'inscription
dimanche 22 avril 2007
Statut
Membre
Dernière intervention
26 avril 2007
-
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() { ... }
kankrelune
Messages postés
1293
Date d'inscription
mardi 9 novembre 2004
Statut
Membre
Dernière intervention
21 mai 2015
-
Comme FhX... je rajouterais juste un détail pas bien méchant mais qui m'a sauté au yeux... enfin ça reste un détail... dans...

$user = new Cookie('user', time() + 30);

et

$user -> setExpiration(time() + 30);

pourquoi ne pas intégrer le time() dans la méthode ça simplifie le truc...

$user = new Cookie('user',30); // temps de vie de 30 secondes
$user->setExpiration(-30); // cookie expiré depuis 30 secondes

Sachant qi'il est plus que rare de trouver un cookie dont le temps de vie est en secondes tu pourrais même passer le paramètre en minutes en intégrant un *60 dans ta méthode... .. .

@ tchaOo°
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
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 :))