CLASSE DE GESTION AVANCÉE DES COOKIES

Signaler
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
-
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 ?