Ben, en parlant d'encapsulation, j'ai encore du mal à déterminer quand un attribut doit être protéger/privé ou public. En ce moment je mets du privé partout car je trouve les getXXX() et setXXX() sexy, mais j'avoue que si quelqu'un a une explication, je suis preneur.


Sephi-Chan

Quand j'ai dit que $var marchait, je voulais dire aussi $this->var, j'ai fait un test, créé une classe avec cette variable, et fait exactement le test du topic :

Et ca a très bien marché.

Concernant le public, je n'utilise quasiment jamais de public, mais pas non plus d'accessor, j'ai l'impression que du moment où tu dois directement accéder aux variables de ta class c'est qu'il y a une erreur de conception quelque part.

Ben dans mon cas, en dehors de l'utilisation d'un Framework, je procédais comme cela :


J'aimais bien, ça me permet d'avoir un code clair. J'utilise ensuite l'objet $user, que je mets en session. Quand je modifie quelque chose, j'utilise les $user->setXXX($xxx); puis je fais un $user->save();


Sephi-Chan

Dans tous langages, il y a des mots clefs et on le sait tous, l'utilisation de ceux-ci est interdite sauf si le langage le permet comme php apparement mais quand on veut éviter de voir apparaitre des bogues, on les évite.
MySQL aussi permet l'utilisation de mot-clefs mais a une condition.

Exemple :
Vous vous êtes jamais demandé pourquoi PMA vous retourner toujours vos champs englobé de ces quotes ?

Donc, pour finir, un conseil que chacun prendra comme il le veut : ne jamais utiliser de mot clefs


Ensuite, accéder aux données cela peut arriver n'importe où, n'importe quand.

C'est juste, je n'avais pas ça en tête
Mais plus des variables nécessaire au fonctionnement de la classe qui ne doivent pas être connu en dehors de la classe en théorie.

Pourquoi ce topo sur les noms réservés (bien que ça ne puisse pas faire de mal de le rappeler ) ? D'autant que datetime n'a pas l'air d'un nom réservé s'il on se réfère à MySQL - Cas des mots réservés MySQL.

Si j'utilise ma méthode, c'est justement pour avoir une API très normalisée. Que l'on s'inscrive, que l'on se connecte ou que l'on édite son profil, ça fait toujours appel à load() ou à save(). Je n'ai pas de login($login, $password), ni de register($login, $password, $email, etc.).

M'enfin, maintenant que je m'essaye aux Frameworks, la question ne se pose plus trop puisqu'ils ont leur fonctionnement.

Ma question, c'est plutôt : quand décide-t-on d'utiliser private/protected ou public. Y a-t-il une astuce ?


Sephi-Chan

Y a pas vraiment d'astuce, il faut juste savoir comment tu compte utilisé les attributs de ta classe et/ou si elle doivent être sécuriser d'une manière ou d'une autre, ça dépend aussi de si tu utilise ou non l'héritage mais là c'est plus pour private/protected. Pour choisir entre protected/private à part dans un cas d'héritage ce n'est que subjectif .

public : Accessible par tout le monde, à utilisé si l'attribut peut être modifier directement sans que cela créer des problèmes.
+: Pas d'appel de fonction
-: Aucun traitement possible à la modification de l'attribut

protected : Accessible par la classe et est transmis en héritage, à utilisé si private n'est pas nécessaire ou que vous voulez protéger un attributs avec des setter et/ou getter avec des traitements.
+: Permet de vérifier l'information donnée avant de la stocker, utile aussi pour l'héritage et le polymorphisme
-: Appel de fonction

private : Accessible uniquement par l'objet.
+: Incorruptible
-: Appel de fonction

L'utilisation de public rend le développement moins lourd puisque on n'utilise pas les setter et getter mais rend aussi le code moins maintenable dans le cas où on doit la protéger plus tard (ce qui n'arrive jamais puisque tout a été bien conçut ).

Ouais… À vrai dire, je sais tout ça. Mais quand je regarde des codes sources, je vois du private/protected et du public, et je me demande toujours pourquoi ils ont décidé que tel ou tel attribut serait privé/protégé ou public. Déjà, à la base, je ne conçois pas que la modification d'un attribut puisse créer des problèmes, mais je suppose que c'est parce que je n'y ai jamais fais face. Si quelqu'un a des exemples de code où on se trouve bien emmerdé avec un public alors qu'un private/protected nous sauve, je suis intéressé.

Je scinderai les sujets si ça dévie, ce n'est pas un souci.


Sephi-Chan

Je me doute mais j'ai essayer d'être clair pour ceux qui connaissaient pas et qui passeraient par là .

Si ton attribut est utilisé par exemple pour une requête SQL tu peux le mettre en public et vérifié tes données avant ta requête mais si tu as décidé de validé tes données au moment de leur modification tu ne vérifie pas une seconde fois au moment de la requête donc un attributs public qui n'est pas contrôlé peut poser problème. Mais bon c'est une question de conception et des choix effectués comme souvent .

Le protected/private te sauve pour un Singleton par exemple ou dans les API et Framework. Utile aussi quand tu travaille en groupe puisque c'est toi qui gère les accés à tes attributs et méthodes de ta classe donc tu évite à celui qui utilise tes classes de devoir faire gaffe à quelles fonctions utilisés ou comment les utilisés.
PHP à implémenter l'Objet mais il ne permet pas autant de chose que les langages qui ont été dés le départ OO, je pense au C++ en particulier même si il faudrait je pense plus comparer avec le Python qui est plus proche.

J'ai pris le premier lien qui me passé par la main : Comment ca marche
Pour faire simple, l'encapsulation des données membres permet de s'assurer de l'intégrité des données.

Private dans tous les cas, Protected si tu souhaites que les classes heritières hérite également de cette donnée.

Si il y a bien une chose qui manque terriblement à php c'est le polymorphisme mais cela on ne le verra peut être pas arriver du fait du faible typage que possède php.